From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from re-prd-fep-042.btinternet.com (mailomta18-re.btinternet.com [213.120.69.111]) by sourceware.org (Postfix) with ESMTPS id F17EE3854830 for ; Fri, 13 Jan 2023 14:28:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F17EE3854830 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-042.btinternet.com with ESMTP id <20230113142812.KWQC30996.re-prd-fep-042.btinternet.com@re-prd-rgout-001.btmx-prd.synchronoss.net>; Fri, 13 Jan 2023 14:28:12 +0000 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613A8CC34AD21B3A 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: gggruggvucftvghtrhhoucdtuddrgedvhedrleekgdeitdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkfffgggfhffuvehfvfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeflohhnucfvuhhrnhgvhicuoehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkqeenucggtffrrghtthgvrhhnpeffveegvdefudeujeelkeeggeeffeefhfevjedvieevgeeghfffhefhgfeihfefieenucffohhmrghinheptgihghifihhnrdgtohhmpdhgihhthhhusgdrtghomhdprhgvphholhhoghihrdhorhhgpdhgnhhurdhorhhgnecukfhppeekuddrudehfedrleekrddvgeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurddutdeingdpihhnvghtpeekuddrudehfedrleekrddvgeeipdhmrghilhhfrhhomhepjhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhdpnhgspghrtghpthhtohepfedprhgtphhtthhopegruggrmhesughinhifohhoughivgdrohhrghdprhgtphhtthhopegthihgfihinhdqrghpphhssegthihgfihinhdrtghomhdprhgtphhtthhopehmrghrtghordgrthiivghrihesghhmrghilhdrtghomh 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 613A8CC34AD21B3A; Fri, 13 Jan 2023 14:28:12 +0000 Message-ID: <05db4660-4d1a-f744-2321-6bc0d423e787@dronecode.org.uk> Date: Fri, 13 Jan 2023 14:28:09 +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 From: Jon Turney Subject: Re: [ITP] libinih Cc: Marco Atzeri References: <20230109163223.74r473jljrxx5zsv@lucy.dinwoodie.org> <0ab55d15-f73d-b471-52c4-07c6acc829fb@dronecode.org.uk> <20230111231637.dbjlug2kpb2oa47i@lucy.dinwoodie.org> Content-Language: en-GB To: Adam Dinwoodie , "cygwin-apps@cygwin.com" In-Reply-To: <20230111231637.dbjlug2kpb2oa47i@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,KAM_SHORT,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 11/01/2023 23:16, Adam Dinwoodie via Cygwin-apps wrote: > On Wed 11 Jan 2023 at 03:14:20PM +0000, Jon Turney wrote: >> 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. > > Makes sense! Here's a rebuild: > > https://github.com/me-and/Cygwin-inih/releases/tag/v56-1-rc2 > >> If you're aware of other packages "done wrong" based on that understanding, >> I guess that's something that needs looking into... > > Ah, I think I was thinking about this backwards. I'd thought that, for > example, make is a problem, because it's not marked as a "*-devel" > package, but it puts a header file in /usr/include as well as all the > files needed by mere users of make.[0] > > [0]: https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fmake%2Fmake-4.4-1 > > It sounds like that's not a problem at all, though: make doesn't provide > any libraries to link against. Wow! So this is a interface for make plugins, new in 4.0 [1] This is actually falling into the "everything is ELF" trap: We also need to provide an import stub lib to link with, so that the PE loader knows which module provides those symbols when they are loaded. (I'd have thought the implib would be named make.exe.a, but the documentation explicitly mentions libgnumake-version.dll.a. Including the version in the implib seems pointless and is going to cause issues if it ever changes, though) Not that there's any evidence anyone actually uses this, but Cc-ing Marco as make maintainer, for information. [1] https://www.gnu.org/software/make/manual/make.html#Loading-Objects Given that it seems intended that the plugin is built as part of the build, I'd speculate that you are saved from soversioning issues by the plugin getting rebuilt when the header changes, but this package is clearly a special case. > What might be more of a problem is something like file, which does > provide a DLL for other packages to link against, and which isn't > separated out into a "lib*" package.[1] > > [1]: https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Ffile%2Ffile-5.41-2&grep=usr%2Fbin%2F.%2A%5C.dll > > (But maybe there's something about file that means we can be confident > it'll never have an soversion change? Almost all my practical I don't know. But that might well be true, if upstream has given it soversion 1 "just in case we ever need to make incompatible changes". So, technically this is wrong, or perhaps just not ideal. Hopefully we'd notice if the soversion changes and evolve the packaging appropriately. At this stage, someone should probably look into the history of this package, and to see if that solib is used by anything other than the python bindings provided by the same package, and how file is packaged by other distros, just to evaluate our risk here. > experience with wrangling library linking is with software appliances > that ignore the issue by replacing all the binaries in an effectively- > atomic operation, so I am well out of my areas of expertise here!) I guess it would be nice if cypgort had some sort of check that you were putting a solib with a version into an unversioned package name, but that might be hard to write reliably...