[ITP] libinih

[Jon Turney]

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