Re: libpaper and gnulib
On Sun, 13 Nov 2022 at 14:01:50 +0000, Reuben Thomas wrote:
> I just got a rejection for libpaper_2.0.3-1 from ftp-master (in this case,
> Thorsten Alteholz), who said "I didn't find any explanation why you embedded a
> copy of gnulib in your source tarball. Do you really need that?"
I think the likely answer is "yes, I really need that subset of
gnulib". Policy §4.13 discourages embedded code copies "unless the
included package is explicitly intended to be used in this way"; but as
you point out, gnulib *is* explicitly intended to be used in this way,
so §4.13 doesn't discourage doing what you're doing.
Perhaps the ftp team member(s) doing the review missed the fact that
libpaper is no longer Debian-specific, and therefore cannot rely on
having all the nice things we get by depending on glibc, even though
in the past it could?
> Some other Debian packages build-depend on Debian's gnulib package. This won't
> necessarily work for libpaper, because gnulib is not versioned: libpaper
> depends on a specific commit of gnulib, and there are often bug fixes or API
> changes.
This is a common policy for "copylibs" like gnulib, libglnx and libegg. If
the copylib's upstream thought it was API-stable, then they'd do formal
releases, or incorporate it into a shared library that has formal
releases and can be used as a dependency; but they don't think that,
so they behave accordingly.
I think the current text of Policy strikes a careful balance. We should
avoid using bundled "convenience copies" of libraries that have their
own independent existence as an API-stable library, like libjpeg, zlib
and SDL, but we shouldn't treat copylibs as though they were API-stable
libraries when that isn't how their upstreams maintain them, particularly
if it comes at the cost of making dependent packages stop work correctly
if they happen to be rebuilt after an incompatible change in the copylib.
Going too far in either direction would be harmful to Debian.
smcv
Reply to: