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