Re: full-source bootstrap and Python

[Simon Josefsson]

Bruno Haible <bruno@clisp.org> writes:

> Janneke Nieuwenhuizen wrote:
>> Are are we creating a problem for
>> bootstrapping (or even a dependency cycle) when introducing this new
>> dependency into a certain package.
>
> I think you answered this question with "no", when writing in [1]:
>
>   "Even more recently (2018), the GNU C Library glibc-2.28 adds Python
>    as a build requirement"
>
> So, how do you avoid Python when building glibc? Do you use musl libc as
> a first stage, and only build glibc once a python built with musl exists?
>
> Also, from the diagrams in [1][2][3] it looks like the full-source bootstrap
> uses tarballs frozen in time (make-3.80, gcc-2.95.3, gcc 4.7.3, etc.). So,
> even if newer versions of 'make' or 'gcc' will use a Python-based gnulib-tool,
> there won't be a problem, because the bootstrap of these old tarballs will
> be unaffected.

While I agree, I think there is one nuance that could be added here: it
is true that full-source bootstraps usually needs to use earlier
releases of software tarballs to build more recent projects because of
cyclic dependencies.  However this cause extra work for people involved.
It also means we will have to keep maintaining and patching all the
software that is involved in the full-source bootstrap to keep it
working in the future.  So there is a cost involved here.

The takeaway from that situation should NOT be "don't use python" or
"don't use modern tools", that would be absurd.

The takeaway should be that one should carefully evaluate the
implications of using Python and modern tools, and look at the costs.

If we want to minimize the work for full-source bootstrap people we
increase the cost of people maintaining modern software, and vice versa,
I don't see how we can get away from this conflict.  If everyone wrote
everything in machine code, there would be nothing for the bootstrap
people to do.

However what we can do is to reduce the total amount of work involved by
not introducing too many bootstrap dependency cycles.  Consider the
extreme situation where gnulib-tool version A would require coreutils
verison B, and coreutils version B+1 would require gnulib-tool version
A+1, and gnulib-tool version A+2 would require coreutils version B+1 and
so on for really short release version increments.  Then a full-source
bootstrap will need to package and keep maintain all those coreutils and
gnulib-tool versions -- or start to patch things to avoid the
dependencies.  (I'm ignoring the fact that normally gnulib-tool is not
involved at all when building projects.)

I think gnulib is already quite careful in dependency tracking, more so
than most projects I'm familiar with, but it doesn't mean this can be
improved.

Janneke: is there any recommendation from you as a bootstrapping person
on what dependency we should be careful with, and which dependencies
that are fine?  I suppose/hope that if gnulib-tool required python
version 2, you would not have a serious problem?  I'm certain that
python version 2 is possible to build using really old toolchains.  At
what version of python would it lead require added another bootstrapping
step to the graph?  Python 3.0, 3.7, 3.12?  Maybe it is not easy to
answer this without generating the graph.  But I also think you would
have a better feeling of what the answer would be than most of us.

/Simon


> Bruno
>
> [1] 
> https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/
> [2] 
> https://guix.gnu.org/manual/en/html_node/Reduced-Binary-Seed-Bootstrap.html
> [3] 
> https://guix.gnu.org/manual/devel/en/html_node/Full_002dSource-Bootstrap.html
>
>
>
>
>

signature.asc
Description: PGP signature