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...
