* [ITP] libinih
@ 2023-01-09 16:32 Adam Dinwoodie
2023-01-11 11:56 ` Lemures Lemniscati
2023-01-11 15:14 ` Jon Turney
0 siblings, 2 replies; 9+ messages in thread
From: Adam Dinwoodie @ 2023-01-09 16:32 UTC (permalink / raw)
To: cygwin-apps
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
~~~
category: Libs
requires: cygwin libgcc1 libstdc++6
sdesc: "Simple .ini file parser"
ldesc: "inih (INI Not Invented Here) is a simple .INI file parser written in C"
~~~
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...
[4]: https://github.com/me-and/Cygwin-inih/pull/1
[5]: https://cygwin.com/pipermail/cygwin/2023-January/252791.html
Cheers,
Adam
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ITP] libinih
2023-01-09 16:32 [ITP] libinih Adam Dinwoodie
@ 2023-01-11 11:56 ` Lemures Lemniscati
2023-01-11 15:14 ` Jon Turney
1 sibling, 0 replies; 9+ messages in thread
From: Lemures Lemniscati @ 2023-01-11 11:56 UTC (permalink / raw)
To: cygwin-apps
On Mon, 9 Jan 2023 16:32:23 +0000, Adam Dinwoodie via Cygwin-apps
> 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
>
> ~~~
> category: Libs
> requires: cygwin libgcc1 libstdc++6
> sdesc: "Simple .ini file parser"
> ldesc: "inih (INI Not Invented Here) is a simple .INI file parser written in C"
> ~~~
>
> 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...
>
> [4]: https://github.com/me-and/Cygwin-inih/pull/1
> [5]: https://cygwin.com/pipermail/cygwin/2023-January/252791.html
Thank you for ITP about inih, which will be necessary for a next release
of exiv2 (cf. [0]).
[exiv2]: https://github.com/Exiv2/exiv2
Lem
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ITP] libinih
2023-01-09 16:32 [ITP] libinih Adam Dinwoodie
2023-01-11 11:56 ` Lemures Lemniscati
@ 2023-01-11 15:14 ` Jon Turney
2023-01-11 23:16 ` Adam Dinwoodie
1 sibling, 1 reply; 9+ messages in thread
From: Jon Turney @ 2023-01-11 15:14 UTC (permalink / raw)
To: Adam Dinwoodie, cygwin-apps
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...
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ITP] libinih
2023-01-11 15:14 ` Jon Turney
@ 2023-01-11 23:16 ` Adam Dinwoodie
2023-01-13 14:27 ` Jon Turney
2023-01-13 14:28 ` Jon Turney
0 siblings, 2 replies; 9+ messages in thread
From: Adam Dinwoodie @ 2023-01-11 23:16 UTC (permalink / raw)
To: cygwin-apps
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.
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
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!)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ITP] libinih
2023-01-11 23:16 ` Adam Dinwoodie
@ 2023-01-13 14:27 ` Jon Turney
2023-01-15 6:12 ` Lemures Lemniscati
2023-01-15 22:49 ` Adam Dinwoodie
2023-01-13 14:28 ` Jon Turney
1 sibling, 2 replies; 9+ messages in thread
From: Jon Turney @ 2023-01-13 14:27 UTC (permalink / raw)
To: Adam Dinwoodie, cygwin-apps
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.
> 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...)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ITP] libinih
2023-01-11 23:16 ` Adam Dinwoodie
2023-01-13 14:27 ` Jon Turney
@ 2023-01-13 14:28 ` Jon Turney
1 sibling, 0 replies; 9+ messages in thread
From: Jon Turney @ 2023-01-13 14:28 UTC (permalink / raw)
To: Adam Dinwoodie, cygwin-apps; +Cc: Marco Atzeri
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...
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ITP] libinih
2023-01-13 14:27 ` Jon Turney
@ 2023-01-15 6:12 ` Lemures Lemniscati
2023-01-15 22:49 ` Adam Dinwoodie
1 sibling, 0 replies; 9+ messages in thread
From: Lemures Lemniscati @ 2023-01-15 6:12 UTC (permalink / raw)
To: cygwin-apps
On Fri, 13 Jan 2023 14:27:46 +0000, Jon Turney via Cygwin-apps
> 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.
>
> > 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...)
I guess, usr/share/ should go to the -devel package, in order to avoid a
situation:
Files under it would have same names between libinih0 and later soversions
(e.g. libinih1). Their contents might be the same, but....
Assume that both of libinih0 and libinih1 are installed,
and if we uninstall libinih0,
and then files under usr/share will be removed unintentionally,
and, moreover, we need reinstall libinih1 to recover the removed files.
Regards,
Lem
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ITP] libinih
2023-01-13 14:27 ` Jon Turney
2023-01-15 6:12 ` Lemures Lemniscati
@ 2023-01-15 22:49 ` Adam Dinwoodie
2023-01-16 12:41 ` Jon Turney
1 sibling, 1 reply; 9+ messages in thread
From: Adam Dinwoodie @ 2023-01-15 22:49 UTC (permalink / raw)
To: Jon Turney; +Cc: cygwin-apps
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!
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ITP] libinih
2023-01-15 22:49 ` Adam Dinwoodie
@ 2023-01-16 12:41 ` Jon Turney
0 siblings, 0 replies; 9+ messages in thread
From: Jon Turney @ 2023-01-16 12:41 UTC (permalink / raw)
To: Adam Dinwoodie, cygwin-apps
On 15/01/2023 22:49, Adam Dinwoodie via Cygwin-apps wrote:
>> 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...)
Unfortunately, this assumption isn't correct.
cygport makes a single debuginfo package for each source package, named
$NAME-debuginfo.
(Consider e.g. if we have libfoo0 and foo-tools made from the foo source
package, the debuginfo for both is placed in foo-debuginfo. It's not
entirely clear to me that we could make a debuginfo package for each
installed package with executable content, since e.g. it contains source
code headers, which would then be duplicated...)
Practically, if someone wants to traverse from an install package to the
matching debuginfo, they have to do it via the source package, but
again, this is emergent behaviour rather than a considered design...
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2023-01-16 12:41 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-09 16:32 [ITP] libinih Adam Dinwoodie
2023-01-11 11:56 ` Lemures Lemniscati
2023-01-11 15:14 ` Jon Turney
2023-01-11 23:16 ` Adam Dinwoodie
2023-01-13 14:27 ` Jon Turney
2023-01-15 6:12 ` Lemures Lemniscati
2023-01-15 22:49 ` Adam Dinwoodie
2023-01-16 12:41 ` Jon Turney
2023-01-13 14:28 ` Jon Turney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).