From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-042.btinternet.com (mailomta11-sa.btinternet.com [213.120.69.17]) by sourceware.org (Postfix) with ESMTPS id 447263858D32 for ; Mon, 16 Jan 2023 12:41:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 447263858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from sa-prd-rgout-003.btmx-prd.synchronoss.net ([10.2.38.6]) by sa-prd-fep-042.btinternet.com with ESMTP id <20230116124150.YZAA16997.sa-prd-fep-042.btinternet.com@sa-prd-rgout-003.btmx-prd.synchronoss.net>; Mon, 16 Jan 2023 12:41:50 +0000 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613942904C264110 X-Originating-IP: [81.153.98.246] X-OWM-Source-IP: 81.153.98.246 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvhedruddtgedggeefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeflohhnucfvuhhrnhgvhicuoehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkqeenucggtffrrghtthgvrhhnpeffkeeigfdujeehteduiefgjeeltdelgeelteekudetfedtffefhfeufefgueettdenucfkphepkedurdduheefrdelkedrvdegieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddruddtiegnpdhinhgvthepkedurdduheefrdelkedrvdegiedpmhgrihhlfhhrohhmpehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkpdhnsggprhgtphhtthhopedvpdhrtghpthhtoheprggurghmseguihhnfihoohguihgvrdhorhhgpdhrtghpthhtoheptgihghifihhnqdgrphhpshestgihghifihhnrdgtohhm X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.106] (81.153.98.246) by sa-prd-rgout-003.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 613942904C264110; Mon, 16 Jan 2023 12:41:50 +0000 Message-ID: <6c09653a-6150-b55d-17ba-ea90c04932d3@dronecode.org.uk> Date: Mon, 16 Jan 2023 12:41:48 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [ITP] libinih Content-Language: en-GB To: Adam Dinwoodie , "cygwin-apps@cygwin.com" References: <20230109163223.74r473jljrxx5zsv@lucy.dinwoodie.org> <0ab55d15-f73d-b471-52c4-07c6acc829fb@dronecode.org.uk> <20230111231637.dbjlug2kpb2oa47i@lucy.dinwoodie.org> <95f61c82-c125-9b93-d7b4-58ba95ee2350@dronecode.org.uk> <20230115224948.fxpb3g5aj4ipcp5w@lucy.dinwoodie.org> From: Jon Turney In-Reply-To: <20230115224948.fxpb3g5aj4ipcp5w@lucy.dinwoodie.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1191.9 required=5.0 tests=BAYES_00,FORGED_SPF_HELO,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 15/01/2023 22:49, Adam Dinwoodie via Cygwin-apps wrote: >> I added this to your packages. >> >>> NAME=libinih >> >> Since the upstream name is just 'inih', the source package should probably >> be named that also. > > Can I double-check how that should work from a package naming > perspective? I *think* that means we'd have: > > - libinih0-$PVR, being the libraries themselves > - libinih0-debuginfo-$PVR, being the debugging symbols for the libraries > - inih-devel-$PVR, being the header, static libraries and pkgconfig files > - inih-$PVR.src, being the source code > > Is that right? In particular, is it right that the debuginfo name > matches the library, while the devel package doesn't? Or should it only > be the source package that has a different name? > > (The build linked above as rc2 has the debuginfo package as > inih-debuginfo, and the devel package as libinih-devel, but on > reflection that doesn't seem quite right to me. If nothing else, I > think I'd expect to find the debug symbols in a package with the same > name as the package I'm debugging...) Unfortunately, this assumption isn't correct. cygport makes a single debuginfo package for each source package, named $NAME-debuginfo. (Consider e.g. if we have libfoo0 and foo-tools made from the foo source package, the debuginfo for both is placed in foo-debuginfo. It's not entirely clear to me that we could make a debuginfo package for each installed package with executable content, since e.g. it contains source code headers, which would then be duplicated...) Practically, if someone wants to traverse from an install package to the matching debuginfo, they have to do it via the source package, but again, this is emergent behaviour rather than a considered design...