Re: autoreconf --force seemingly does not forcibly update everything

[Simon Josefsson]

Guillem Jover <guillem@debian.org> writes:

> But if as a downstream distribution I explicitly request everything to
> be considered obsolete via --force, then I really do want to get whatever
> is in the system instead of in the upstream package. Because then I
> can fix things centrally in a distribution dependency package, instead
> of having to wait for upstreams to do so, for example, or because then I
> have a higher chance of building from known system files instead of
> local stuff.

I think that is the perception that leads to problems: 'autoreconf -f
-i' will not give you what you are looking for even if we make '-f' pull
in *.m4 files regardless of serial number.  There will be other files
that are not updated from the central system package.  It was never
intended as a re-bootstrapping tool.

Nick Bowler <nbowler@draconx.ca> writes:

> On 2024-04-01 16:43, Guillem Jover wrote:
>> But if as a downstream distribution I explicitly request everything
>> to be considered obsolete via --force, then I really do want to get
>> whatever is in the system instead of in the upstream package.
>
> If I distribute a release package, what I have tested is exactly what is
> in that package.  If you start replacing different versions of m4 macros,
> or use some distribution-patched autoconf/automake/libtool or whatever,
> then this you have invalidated any and all release testing.
>
> This is fine, modifying a package and distributing modified versions
> are freedoms 1 and 3, but if it breaks you keep both pieces.
>
> The aclocal --install feature should be seen as a feature to help update
> dependencies as part of the process of preparing a modified version, not
> something that should ever be routinely performed by system integrators.
>
> GNU/Linux distributions have a long history of buggy backports to the
> autotools.  For a recent example, Gentoo shipped a broken libtool 2.4.6
> which included a patch to make Gentoo installs go faster but if you
> prepared a package with this broken libtool version, the resulting
> package would not build on HP-UX, oops.

Indeed, I think distributions are using autoconf tools in unintended
ways, and when repeatedly being told so, the response has usually been
"we know what we are doing, and want it our way for portability".
Usually because distribution packagers find it easier to run 'autoreconf
-fi' than to patch config.guess etc to support new targets.

That said, co-operation between GNU and Debian has been historically
poor, and we should try to collaborate and keep the lowest common
denominator between the projects as healthy as possible.  So if there is
something that can be improved, let's do that, but let's base it on good
design rather than "I want it my way".  I think the fundamental feature
request -- to re-bootstrap all generated files -- from Guillem is a fair
request, and arguable the GNU project has not been helpful to provide
this historically.  Instead the approach has been "we want various files
to be included in the tarball for portability".  This approach is still
important for porting to new targets, but has a cost in that it makes
auditing harder.  I believe we can support both the old way (*.tar.gz
with pre-generated content, impossible to fully re-bootstrap reliably
without risks) and a new way (*-src.tar.gz with just source code) at the
same time.  This appears to me more reliable than to fix all kind of
re-bootstrapping problems with 'autoreconf -f -i'.

/Simon

signature.asc
Description: PGP signature