bug-inetutils
[Top][All Lists]
Advanced

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

Re: Gnulib & bootstrap updates


From: Simon Josefsson
Subject: Re: Gnulib & bootstrap updates
Date: Wed, 08 May 2024 22:06:39 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Guillem Jover <guillem@hadrons.org> writes:

> Hi!
>
> On Mon, 2024-05-06 at 18:12:53 +0200, Simon Josefsson via Bug reports for the 
> GNU Internet utilities wrote:
>> I have updated inetutils to latest gnulib (to get the u_* syntax-check
>> fixes, and the new faster gnulib-tool.py) and refreshed the bootstrap
>> scripts, please test and report if something broke!
>
> Could you consider shipping at least the bootstrap.conf, but ideally
> also the bootstrap script in the released tarballs, so that it's easy
> to regenerate from gnulib at build time?
>
> (In Debian I'm currently shipping the upstream boostrap.conf as a
> local file, which I'd like to eventually drop.)

Hi Guillem.  I added the bootstrap files to the tarball now.

I'm not convinced that this is a good idea, so let's consider this an
experiment.  First, this is not recommended by gnulib documentation.
Several GNU projects (like coreutils) ship the scripts, and it is good
license compliance hygiene to include all source code, so maybe that is
a gnulib documentation problem -- but I suspect the reason for this lack
of recommendation are due to the second and third issues.

Secondly, running ./bootstrap from a tarball without a .git directory
will die like this:

  ./bootstrap: Bootstrapping from a non-checked-out distribution is risky.

You need to supply --force to avoid this.

Thirdly, which is the reason for the warning, I think people jump to the
wrong conclusion of what running './bootstrap --force' in a normal
(non-minimal) tarball will actually achieve.  What do you hope to
achieve?  Just like running 'autoreconf -fi', running './bootstrap
--force' will NOT re-bootstrap all generated files if you assumed that
(which is unfortunately all too easy to assume).  It may happen to work
for some packages, some of the time, and to re-generate some of the
files, but this 95% correct is a characteristic of many dark patterns.

Would you consider building the Debian package from a PGP signed 'git
archive'-style tarball instead?  If so we could do an alpha release of
that and see how it works for you (the Debian gnulib package needs to be
updated first though, but that's on my todo list).

/Simon

Attachment: signature.asc
Description: PGP signature


reply via email to

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