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. Bruno
