Re: [ITP] libinih

[Adam Dinwoodie <adam@dinwoodie.org>]

On Fri, Jan 13, 2023 at 02:27:46PM +0000, Jon Turney wrote:
> 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].
> > > > 
> [...]
> > > This looks good, except...
> > > 
> > > I'd ask you to split this into libinih0 and libinih-devel packages.
> [...]
> > 
> > Makes sense!  Here's a rebuild:
> > 
> > https://github.com/me-and/Cygwin-inih/releases/tag/v56-1-rc2
> Thanks.
> 
> 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...)

> > libinih0_CONTENTS="\
> >   usr/bin/*.dll\
> >   usr/share/\
> > "
> 
> You probably want to write this glob as '*-0.dll', so that when the
> soversion changes, packaging fails, rather than silently ploughing on to
> contain a libinit0 containing cyginit-1.dll...
> 
> (Or factor out the soversion as variable, or something...)

Done, thank you for the suggestion!