Janneke Nieuwenhuizen wrote:
> For the current situtation (that's less than great and are
> working on to resolve), making essential GNU packages less
> bootstrappable is of no consequence.
OK. That's what I conjectured. Thanks for confirming.
> Cleaning-up the full-source
> bootstrap and making
Janneke Nieuwenhuizen writes:
>> 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 pro
Simon Josefsson wrote:
> If we want to minimize the work for full-source bootstrap people we
> increase the cost of people maintaining modern software, and vice versa,
+1
> Consider the
> extreme situation where gnulib-tool version A would require coreutils
> verison B, and coreutils version B+1
Bruno Haible writes:
Hi!
> 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 recent
Bruno Haible 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 (
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.2
