I am the upstream maintainer of libpaper (which used to be a pure-Debian project), and also a Debian Maintainer trying to get a new version of
libpaper into Debian. (It involves an API/ABI transition, from the current libpaper1 to libpaper2.)

Bastian Germann (bage@debian.org) is kindly helping with the packaging and sponsoring my upload.

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?"

Like many GNU packages, my rewrite of libpaper uses gnulib, a source
library that's effectively a polyfill for POSIX & GNU APIs, and my libpaper releases distribute some gnulib source files as part of the release
tarball. Other Debian packages that work this way include coreutils and
grep.

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.

Bastian asked me to build-depend on gnulib, which I have so far declined to
do, as that would make the Debian package's sources effectively different
from those that I release as upstream maintainer.

Also, a build-depend on gnulib would not directly address Thorsten's
problem with the package, as the source archive would still contain gnulib sources (although maybe it would be OK if they weren't used?). I had a look
at a package that does build-depend on gnulib, wget2, and its source
tarball contains gnulib files.

I have searched the debian-devel archives and found a few reference s to gnulib, but no definitive ruling about how gnulib should be treated.
Bastian rightly points out that by including gnulib sources, packages such
as coreutils cannot easily be updated for security bugs in gnulib; but to
me this seems to be a problem with gnulib itself (it's a source library,
that's how it works), rather than with the packaging of programs that use gnulib.

Another of Bastian's suggestions is that I base the Debian package on a git snapshot, as that does not include gnulib files; but this still has the
problem that the Debian package would not be built from a release of
libpaper.

I am a bit torn here: with my DM hat on, stripping out gnulib sources where possible and using Debian's gnulib package seems the right thing to do.
With my upstream hat on it leads potentially to bug reports that don't correspond to an upstream release; and further few Debian packages that use gnulib actually seem to use this method (there are 26 build-rdeps of
gnulib).

Help? (With many thanks to the several DDs that have already helped on the nearly 10-year journey to get libpaper updated!)

--
https://rrt.sc3d.org

<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I am the upstream maintainer of libpaper (which used to be a pure-Debian project), and also a Debian Maintainer trying to get a new version of
libpaper into Debian. (It involves an API/ABI transition, from the current libpaper1 to libpaper2.)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:
arial,helvetica,sans-serif;font-size:small">Bastian Germann (<a href="mailto:bage@debian.org">bage@debian.org</a>) is kindly helping with the packaging and sponsoring my upload.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-
serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I just got a rejection for libpaper_2.0.3-1 from ftp-master (in this case, Thorsten Alteholz), who said &quot;I didn&#39;t find any
explanation why you embedded a copy of gnulib in your source tarball. Do you really need that?&quot;</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:
arial,helvetica,sans-serif;font-size:small">Like many GNU packages, my rewrite of libpaper uses gnulib, a source library that&#39;s effectively a polyfill for POSIX &amp; GNU APIs, and my libpaper releases distribute some gnulib source files as part of
the release tarball. Other Debian packages that work this way include coreutils and grep.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,
helvetica,sans-serif;font-size:small">Some other Debian packages build-depend on Debian&#39;s gnulib package. This won&#39;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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Bastian asked me to build-
depend on gnulib, which I have so far declined to do, as that would make the Debian package&#39;s sources effectively different from those that I release as upstream maintainer.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-
serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Also, a build-depend on gnulib would not directly address Thorsten&#39;s problem with the package, as the source archive would
still contain gnulib sources (although maybe it would be OK if they weren&#39;t used?). I had a look at a package that does build-depend on gnulib, wget2, and its source tarball contains gnulib files.</div><div class="gmail_default" style="font-family:
arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I have searched the debian-devel archives and found a few reference s to gnulib, but no definitive ruling
about how gnulib should be treated. Bastian rightly points out that by including gnulib sources, packages such as coreutils cannot easily be updated for security bugs in gnulib; but to me this seems to be a problem with gnulib itself (it&#39;s a source
library, that&#39;s how it works), rather than with the packaging of programs that use gnulib.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,
helvetica,sans-serif;font-size:small">Another of Bastian&#39;s suggestions is that I base the Debian package on a git snapshot, as that does not include gnulib files; but this still has the problem that the Debian package would not be built from a
release of libpaper.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I am a bit torn here: with my DM hat
on, stripping out gnulib sources where possible and using Debian&#39;s gnulib package seems the right thing to do. With my upstream hat on it leads potentially to bug reports that don&#39;t correspond to an upstream release; and further few Debian
packages that use gnulib actually seem to use this method (there are 26 build-rdeps of gnulib).<br></div><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default">Help? (With many thanks to the several
DDs that have already helped on the nearly 10-year journey to get libpaper updated!)<br></div><br></div>-<span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">- </span><br><div dir="ltr" class="gmail_signature" data-
smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><a href="https://rrt.sc3d.org" target="_blank">https://rrt.sc3d.org</a></div></div></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This message is in MIME format and has been PGP signed.

Hi,

On So 13 Nov 2022 15:01:50 CET, Reuben Thomas wrote:

I am a bit torn here: with my DM hat on, stripping out gnulib sources where possible and using Debian's gnulib package seems the right thing to do.
With my upstream hat on it leads potentially to bug reports that don't correspond to an upstream release; and further few Debian packages that use gnulib actually seem to use this method (there are 26 build-rdeps of
gnulib).

You could use the global File-Excluded: header in debian/copyright.
This could then strip off the gnulib files from your libpaper code.

And with File-Excluded: make sure you use the the --repack option for
uscan when retrieving the orig tarball from the upstream source
location.

About bug reports: people should report to Debian's bug tracker first
anyway and then let the maintainer decide whether to forward to
upstream or not.

I using this orig tarball repacking for several of my packages (also
for ripping out non-Linux code that I don't want to attribute in debian/copyright) and it is working nicely.

If you are interested, I can dig out some example packages that show
this technique.

Mike



--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCgAdFiEEm/uu6GwKpf+/IgeCmvRrMCV3GzEFAmNxF8YACgkQmvRrMCV3 GzEnwQ/+JLyDI5pXQTDkO5LbkrUUby4SQS3uhckO+W9EW6N2RasOKPpWaa59hX5a X/k1No9rvCVvl78bXXkQh4Y7/Jejh/7hi43yGKslJY8RorOpqY/pBnC+TJNes+OT M993pPv2OHnzZ6QoT3n1Ulkbo6F2kv6XUDE9+3MKwOy71+OcHhskMWfDN3phy++d /02B3D1jPNE0Hoznr5jRvXROiSlB0ChP/RAy93xkT5ZRDiRlIksz4PO7+Nm7OzoQ uhK07Ie8ktrU7DJSgRLVNyFzglIh1DWApDDyKyD3uPRouBbbsN9v1R5JqxoQgeXI tr4GIJueLc4T89N3mNvX/xJqPl0NsreHThk8W0X1GLsm/WlGypR4oqtBMkEUOHQT XQ7oCzzSMrAWk6zN3OAjiqQlNzGS24IqFhENwlHyo5x0a9MYGR1L97UUquayg4E5 WQJpUueJT9gSxfGK2JQsPXIL+aQlzaI2IIAjMUWXV53Z4RaVmj2J3jILb0Ol3bUV CZc9Te0PzenxwyeKwVGK9uqA1W3dwrBiW8/SUNzbnAcR

"Reuben" == Reuben Thomas <rrt@sc3d.org> writes:

Reuben> I am a bit torn here: with my DM hat on, stripping out
Reuben> gnulib sources where possible and using Debian's gnulib
Reuben> package seems the right thing to do. With my upstream hat
Reuben> on it leads potentially to bug reports that don't correspond
Reuben> to an upstream release; and further few Debian packages that
Reuben> use gnulib actually seem to use this method (there are 26
Reuben> build-rdeps of gnulib).

I think Simon has given you a good specific answer for this situation.

Generally, though, you are wearing different hats when you are
maintaining a Debian package and when you are upstream.
Often, it is better for Debian if the Debian sources are not entirely
the same as the upstream sources.
When wearing your DM hat, you should do what's best for Debian, even if
it makes your upstream hat a bit grumpy, keeping in mind things like:

* In this case, Simon has argued that it is better for Debian to use the
source library.

* Making upstream too grumpy isn't good for Debian

* Adequate testing is good for Debian.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

在 2022-11-13星期日的 14:01 +0000，Reuben Thomas写道：

I am the upstream maintainer of libpaper (which used to be a pure-Debian project), and also a Debian Maintainer trying to get a new version of libpaper into Debian. (It involves an API/ABI transition, from the current libpaper1 to libpaper2.)

I am a bit torn here: with my DM hat on, stripping out gnulib sources
where possible and using Debian's gnulib package seems the right thing to
do. With my upstream hat on it leads potentially to bug reports that don't correspond to an upstream release; and further few Debian packages that
use gnulib actually seem to use this method (there are 26 build-rdeps of gnulib).

With my _de facto_ Debian gnulib package maintainer on (background: package gnulib has been under Debian QA Group umbrella for many years; I have been maintaining it with QA uploads for several years.), I would be glad to help
you either when you act as an upstream libpaper developer or as Debian's DM.
I would encourage ensuring your project (libpaper) to keep source-level compatibility with gnulib src versions both in Debian's repo, in your (upstream) embedded gnulib copy, as well as the gnulib upstream trunk(!). Enforcing it with some unittests would be great. If you find the current version in Debian not appropriate, feel free to ping me for a patch /
update.

As you might know, gnulib hasn't been providing releases for over a decade.
The current maintenance in Debian is about packaging a reasonably new
upstream snapshot. I tried to enable as much as upstream test suites as possible to make sure that things don't break. If anything breaks and
affects you, feel free to submit a bug report and ping me.

Thanks,
Boyuan Yang

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAmNxdbQACgkQwpPntGGC Ws60QRAAwr9WQR0Lp8jRGMrMyO2WpE25SUUTUFX8XaNzkbqsLEt1jCla5RVNnvaS pl2/lX0c7U2QApvzVVaLNlZEdlASXfMwzYHCeuXI8rIcg+Cc7nn1X57SapH89U5m Ugzca3KgynsiiiPeSYDq2K2XNotG5aAm1Hy0L1+dwZHcxWYIaWhDfAHxAQIHIU0k YsNfvrHSNvZ+E+jfGvce0ACWSzj3ScdTwNkG1op85qRWMuyA0oiZ7s+nWxagQ4HT 1JoFixnEY+51LinAs+W+QgC7inwdl7FfB2DfQELhMj6OMKhsP2u8Ohkzv9WRkrlF MRtGWa+cDCKcT/stvJL+3kKlectn0vAg9/UL9b+MqlFJYjVDIpGHoHPvhFd0QAU9 Vr6GtnhkPBVbKc3UdbOES4Ul/Jg8MiInJ9Dc8OKnD9scpgnexdUdk1i6rOFO/Vbu Za8VtWWTw+y0fia5FNXuolfJFq48LEtYGnS05wdrYYalzdcZsl53QAZwTRvtlBBs kIT45SFUX9YemNXdgiBPAnKxbOVc8aeIjocTCHBQty3yta57nYW8miLi5VeD+c7N UZ/91jMcZi+qIX93LFEQH5dtkOeiX5QyJnzVcn40Whc0cOHZmsHznFt8iS9CDmN0 vglUphSWeWTrD6gkQbDnvlBVZKQXjUpffbiDkHt2fGs5s56dSJE=
=9nAB
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Nov 13, 2022 at 02:01:50PM +0000, Reuben Thomas wrote:

I am the upstream maintainer of libpaper (which used to be a pure-Debian project), and also a Debian Maintainer trying to get a new version of libpaper into Debian. (It involves an API/ABI transition, from the current libpaper1 to libpaper2.)

Bastian Germann (bage@debian.org) is kindly helping with the packaging and sponsoring my upload.

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?"

Even if you do end up build-depending on gnulib, I see no reason why you
should strip the files out of the source tarball. There's no
DFSG-freeness issue here, and removing them would introduce unnecessary complexity (even if uscan makes it mostly straightforward these days,
it's still more complex than not doing it; and the files containing
elements from Gnulib are by no means neatly confined to a single
directory or anything like that).

Other things to consider:

* upstreams rarely (if ever?) track exactly how new a version of Gnulib
they need due to its typical use as a copylib, so build-depending on
the packaged version would likely make backports harder (keeping the
files in the source package would mitigate this a bit since at least
backports could drop the build-dependency if they needed to);

* although Boyuan Yang has been doing a good job recently at keeping
the package updated and I don't want to throw any shade in their
direction, I think I am probably not the only person who would be
slightly uneasy about introducing a build-dependency from (at least
in some cases) rather critical packages to a QA-maintained package
whose only active packager for the last three years seems reluctant
to take over full maintainership;

* interactions between upstream code and Gnulib can be pretty subtle,
so consider if you're really prepared to debug the FTBFS reports
likely to result from using a different commit from upstream, on an
ongoing basis;

* the "unless the included package is explicitly intended to be used in
this way" language in Policy 4.13 was specifically intended to cover
Gnulib, and IMO ftpmaster should take that into account (see
https://bugs.debian.org/392362).

Notwithstanding this, I'll have a look at my own packages that use
Gnulib to see if it's reasonably practical these days to switch to using
the packaged version. I don't think this is going to be a quick
decision for me. Part of my concern based on over 15 years of
experience with using Gnulib is that I'm unsure whether this is going to introduce an unreasonable amount of breakage over time, rather than
necessarily whether it will work right now.


I had a look through my email archives, and found a discussion about
this way back in 2008 in the context of some other package, where I
wrote this response (in part). I think it still largely stands up.

========================================================================

During the debian-policy discussion, Ian Jackson brought up the question
"When we find a /tmp handling vulnerability in gnulib, will we not have
a serious problem?", which is likely to be the core of ftpmaster's
concern here. I understand this type of concern since Gnulib does indeed contain some /tmp-handling functions, although mostly just very basic
ones (for example it provides replacements for mkstemp and mkdtemp). I
think this type of concern is mitigated for the following reasons,
though:

* While (as others have brought up) you need to be careful about it,
Gnulib makes it easy for upstreams to keep up to date using
'gnulib-tool --update', and so they generally do. (You'd get a lot
more skew if they had to copy files in by hand.)

* Gnulib is IMO best regarded as the other half of Autoconf (the bit
that actually supplies replacements for all those functions that
configure scripts check for ...), and we're well used to Autoconf
working this way. Which is better: having each upstream maintainer
write their own replacements, or having a common repository of them
in Gnulib? I know which I prefer.

* Gnulib is maintained by many of the same people who maintain things
like the core GNU utilities and are frequent contributors to GNU
libc. I know that arguments based on people's competence are not the
best since (a) security holes crop up in even the best code and (b)
of course everyone says *they're* competent, but at least my
experience of Gnulib has really been very good.

* The usual argument is that these functions should go in a shared
library instead. In fact, many of them do, namely libc - in a number
of cases this code isn't used on Debian. In cases where it is
(xmalloc, xasprintf, execute_java_class, etc.) I think it's
nevertheless better than people rolling their own slightly different
versions.

* The functions that Gnulib tends to provide are basically those that
are in libc or little things that lots of upstreams tend to
implement themselves (badly). In pretty much every case, equivalent
code would be in the package anyway; if you forbid the use of Gnulib
then they'll just write it themselves! gnulib-tool only copies the
files that are actually used.

* One effect that I have noticed in using Gnulib as an upstream is
that, because it provides implementations of GNU-specific functions
for systems that lack them, I am much more likely to be willing to
use those functions. Despite the fact that some code ends up being
copied around as a fallback measure (much of it not used when built
on Debian, as above), this comes out as a net win as far as security
is concerned. I'd much rather live in a world where people use
Gnulib and so are willing to use non-portable functions like
asprintf, canonicalize_file_name, openat, and so on than our current
world which is still full of stupid vulnerabilities due to people
getting sprintf or realpath buffer sizes wrong or race conditions
while traversing directory trees.

========================================================================

--
Colin Watson (he/him) [cjwatson@debian.org]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks very much to all those who have given advice, offered help, and
spelt out some of the background of gnulib use in Debian.

The summary seems to be that using gnulib in its usual way to embed files
used by APIs a package uses is acceptable.

--
https://rrt.sc3d.org

<div dir="ltr"><div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default">Thanks very much to all those who have given advice, offered help, and spelt out some of the background of gnulib use in Debian.</div><div style=
"font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default">The summary seems to be that using gnulib in its usual way to embed files
used by APIs a package uses is acceptable.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><a href="https://rrt.sc3d.org" target="_blank">https://rrt.sc3d.org</a><
/div></div></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Nov 13, 2022 at 02:01:50PM +0000, Reuben Thomas wrote:

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.

I think bug fixes is something you'd want. API changes less so.

Also note that gnulib is a piece that regularly faces portability issues
(as it tries to provide portability). As such, it is particularly
annoying for porters to not only have to fix gnulib, but then also have
to get it updated in tons of downstreams. I stopped counting the number
of bug reports "... ships a broken, outdated, embedded copy of gnulib"
that I've sent. As a porter, I very much wish people wouldn't embed
gnulib.

This is just one argument from a very specific point of view. It does
not invalidate your arguments. The final resolution of this question
will remain an individual compromise.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 16 Nov 2022 at 09:47, Helmut Grohne <helmut@subdivi.de> wrote:

I think bug fixes is something you'd want. API changes less so.

My point was that there are frequently bug fixes and API changes since
whatever version of gnulib is packaged in Debian.

Also note that gnulib is a piece that regularly faces portability issues
(as it tries to provide portability). As such, it is particularly
annoying for porters to not only have to fix gnulib, but then also have
to get it updated in tons of downstreams.

How is this a problem for Debian packagers? Once software is packaged for Debian, it's already known to build and run.

I stopped counting the number

of bug reports "... ships a broken, outdated, embedded copy of gnulib"
that I've sent. As a porter, I very much wish people wouldn't embed
gnulib.

I agree, gnulib as a whole shouldn't be embedded. I also agree that
software that uses gnulib, even small parts of it (like libpaper) will have
to update from time to time to fix bugs and portability problems.

--
https://rrt.sc3d.org

<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 16 Nov 2022 at 09:47, Helmut Grohne &lt;<a href="mailto:helmut@subdivi.de">helmut@subdivi.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I think bug fixes is something you&#39;d want. API changes less so.<br></blockquote><div><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default">My point was that there are frequently bug fixes and API changes
since whatever version of gnulib is packaged in Debian.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also note that gnulib is a piece that regularly faces portability issues<br> (as it tries to provide portability). As such, it is particularly<br>
annoying for porters to not only have to fix gnulib, but then also have<br>
to get it updated in tons of downstreams.</blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default">How is this a problem for Debian packagers? Once software is packaged for Debian, it&#39;s
already known to build and run.<br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I stopped counting the number<br>
of bug reports &quot;... ships a broken, outdated, embedded copy of gnulib&quot;<br>
that I&#39;ve sent. As a porter, I very much wish people wouldn&#39;t embed<br> gnulib.<br></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default">I agree, gnulib as a whole shouldn&#39;t be embedded. I also agree that software that uses gnulib, even small parts of
it (like libpaper) will have to update from time to time to fix bugs and portability problems.<br></div></div></div><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><a href="https://rrt.sc3d.org" target="_blank">https:/
/rrt.sc3d.org</a></div></div></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Nov 19, 2022 at 11:37:36AM +0000, Reuben Thomas wrote:

How is this a problem for Debian packagers? Once software is packaged for Debian, it's already known to build and run.

It is known to build and run on some architectures. We are slowing down
from adding one architecture per year to one architecture every other
year. And given the long tail of problems, porters have to fix gnulib
copies for a long time. People used to say that we can ship generated
configure scripts (and some still do). Now we autoreconf by default,
because arm64 was just too painful. gnulib affects a lot less packages,
but has a similar impact otherwise.

Note that this represents a very porter-centric point of view. It is an isolated argument in favour of not embedding gnulib ignoring many other arguments that can be made for both sides of the equation.

And if you decide to vendor gnulib anyway, don't forget to register
yourself with the security tracker!

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 21 Nov 2022 at 21:30, Helmut Grohne <helmut@subdivi.de> wrote:

It is known to build and run on some architectures.

Excellent point! I already mitigate this risk by building most of my
(upstream) packages on macOS and Windows as well as GNU/Linux, but still.

And if you decide to vendor gnulib anyway, don't forget to register

yourself with the security tracker!

Excellent suggestion, thanks.

--
https://rrt.sc3d.org

<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">On Mon, 21 Nov 2022 at 21:30, Helmut Grohne &lt;<a href="mailto:helmut@subdivi.de">helmut@subdivi.de</a>&gt; wrote:<br></div></div><
div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It is known to build and run on some architectures.</blockquote><div><br></div><div><div style="
font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default">Excellent point! I already mitigate this risk by building most of my (upstream) packages on macOS and Windows as well as GNU/Linux, but still.</div><br></div><blockquote class="
gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

And if you decide to vendor gnulib anyway, don&#39;t forget to register<br> yourself with the security tracker!<br></blockquote><div><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default">Excellent suggestion, thanks.</div></div><br>-- <br><div dir="ltr" class="gmail_signature"><div
dir="ltr"><div><div dir="ltr"><a href="https://rrt.sc3d.org" target="_blank">https://rrt.sc3d.org</a></div></div></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)