bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stable branches for Gnulib


From: Bernhard Voelker
Subject: Re: stable branches for Gnulib
Date: Sun, 11 Sep 2022 01:19:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1

On 9/10/22 20:36, Bruno Haible wrote:
Bernhard Voelker wrote:
1. New upstream / GNU package release.
Usually, GNU maintainers pull in the latest changes from gnulib before making
a new release.  Well, at that time, a lot of platform tests are done, and
most problems are found instantly, I'd say.
If not, well, then the issue gets fixed in gnulib and a re-release is done
with a newer version.

Yes, and it is in this "re-release with a newer version" step that it is
challenging to not regress. The stable branches help doing that in some
cases. Not always — because we don't have a stable branch that starts
at precisely the date of the earlier release.

2. Downstream builds.
2a) New downstream build for a new upstream release.
When a new upstream version of a package doesn't work, then either the 
downstream
maintainer can pick the fix from gnulib as a patch

This is true in simple cases. But in the case of the Linux/ppc64le build
failure, two Red Hat employees attempted this and came back, after 6 months,
essentially saying "we did not succeed". The reason is that cdefs.h and
libc-config.h changes are not simple.

Similarly, the 'tempname' fix that Paul did recently involved other modules as
dependencies. Distro downstream maintainers cannot "pick" such a change from
Gnulib reliably.

Thanks., good points, I agree.
It's good if some few work on gnulib can save some huge work somewhere else
in some cases.  Actually this is the whole point about gnulib.

Have a nice day,
Berny



reply via email to

[Prev in Thread] Current Thread [Next in Thread]