From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from re-prd-fep-047.btinternet.com (mailomta12-re.btinternet.com [213.120.69.105]) by sourceware.org (Postfix) with ESMTPS id CF5AC3858C83 for ; Wed, 11 Jan 2023 15:14:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CF5AC3858C83 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 re-prd-rgout-001.btmx-prd.synchronoss.net ([10.2.54.4]) by re-prd-fep-047.btinternet.com with ESMTP id <20230111151422.XXKF20465.re-prd-fep-047.btinternet.com@re-prd-rgout-001.btmx-prd.synchronoss.net>; Wed, 11 Jan 2023 15:14:22 +0000 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613A8CC34A947FAD 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: gggruggvucftvghtrhhoucdtuddrgedvhedrleeggdejfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepkeeijeffgfdugeejteefueeljeffveelkeffvddvveetgffhgfelgfeuvddvhfefnecuffhomhgrihhnpegthihgfihinhdrtghomhdpghhithhhuhgsrdgtohhmpdhrvghpohhlohhghidrohhrghenucfkphepkedurdduheefrdelkedrvdegieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddruddtiegnpdhinhgvthepkedurdduheefrdelkedrvdegiedpmhgrihhlfhhrohhmpehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkpdhnsggprhgtphhtthhopedvpdhrtghpthhtoheprggurghmseguihhnfihoohguihgvrdhorhhgpdhrtghpthhtoheptgihghifihhnqdgrphhpshestgihghifihhnrdgtohhm X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.106] (81.153.98.246) by re-prd-rgout-001.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 613A8CC34A947FAD; Wed, 11 Jan 2023 15:14:22 +0000 Message-ID: <0ab55d15-f73d-b471-52c4-07c6acc829fb@dronecode.org.uk> Date: Wed, 11 Jan 2023 15:14:20 +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 To: Adam Dinwoodie , "cygwin-apps@cygwin.com" References: <20230109163223.74r473jljrxx5zsv@lucy.dinwoodie.org> Content-Language: en-GB From: Jon Turney In-Reply-To: <20230109163223.74r473jljrxx5zsv@lucy.dinwoodie.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3570.0 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 09/01/2023 16:32, Adam Dinwoodie via Cygwin-apps wrote: > As requested at [0], I've offered to package libinih for Cygwin. It has > a BSD license[1] and is already packaged for a bunch of *nix distros, > including Fedora, Debian and Arch[2]. > > [0]: https://cygwin.com/pipermail/cygwin/2023-January/252780.html > [1]: https://github.com/benhoyt/inih/blob/master/LICENSE.txt > [2]: https://repology.org/project/inih/versions > > Provisional release packages are available at [3], and I've copied the > main .hint file below for reference. > > [3]: https://github.com/me-and/Cygwin-inih/releases/tag/v56-1-rc1 Thanks. This looks good, except... > I've not maintained this sort of library before; I've defaulted to > including everything in a single package, but Lem suggested splitting > out a -devel package to contain the header files[4][5]. I don't think > it makes much difference either way -- the monolithic package is only > ~16 KB compressed -- and it seems plenty of other Cygwin packages have > their header files in the same package as the runtime package, but I'd > appreciate thoughts from everyone else on what's thought to be best > practice these days... I'd ask you to split this into libinih0 and libinih-devel packages. Firstly, I don't want to get into making judgements about what the size threshold is for a package to be "small enough to not bother". Secondly, I think, if there's ever a soversion change (i.e. cyginih-0.dll becomes cyginih-1.dll), structuring it as a single package makes it impossible to parallel install the old and new soversions together, thus breaking any other packages linked with the old soversion until they are rebuilt. If you're aware of other packages "done wrong" based on that understanding, I guess that's something that needs looking into...