plans and wishes

Greg Schafer gschafer at
Wed Jan 14 19:30:49 PST 2004

On Thu, Jan 15, 2004 at 01:04:08PM +1100, Ryan.Oliver at wrote:
> > is a noble goal and quite logical. But my ICA stuff which is based on
> > comparing actual bytes leads me to believe that this notion is not
> > that important, mainly because the core toolchain is already so
> > beautifully taken care of in early Ch 6.
> Too true, but hey, I'm anal :-)

Yes, but in this case, for no good factual reasons :-)

> Ch6 after the toolchain is open slather, even if we do it
> alphabetically by a naming quirk the autotools, bison, coreutils will still
> be built early ( though also best to get m4/bison/flex/make
> built early ch6 ).

I disagree. I think you're underestimating the effectiveness of the very
plfs build method you designed :-)  Well, if not underestimating, then at
least letting uncertainty creep in. To put it bluntly, there are no facts to
cause your uncertainty, only feelings of doubt.

Back when we were developing plfs, I admit to being affected by this
uncertainty factor too. But it's really unfounded. I suppose I now have a
unique view of all of this due to all the work I've put in looking at
reproducibility. Because when it boils down, _that_ is what this whole
discussion is all about. Reproducibility is a fact that can be proven with
hard data. All this "touchy feely" stuff is just bollocks :-)

> As long as the gnu dev suite is in place early we keep our build
> relatively future proof, regardless of what gets thrown our way.
> (another reason for the initial ch5 build sequence,
> though m4/bison/flex have been dropped from LFS-5 ch5 )

m4/bison/flex are simply not needed. Tarballs generally include the files
generated by these tools. This is a fact. As you well know, only when using
HJL binutils are they required. LFS is currently not using HJL binutils so
there is no point in using them. If they made a difference to the LFS build
then we'd need them, but the facts of the matter are they currently make no
difference. We can easily add them if they're needed in future.

> Ideally you'd also have libtool near the start too in case of
> future invasive patches requiring the whole libtoolize/autoheader/
> automake/autoconf routine...

Ughh! No thanks. We'll avoid invasive patches like the plague :-) Again, we
can always adjust if ever the need arises. Often, the need for autotools is
circumvented by patching the generated files instead of the source files
(e.g. configure vs, vs

> The one thing your ICA tests wont show up is the difference between
> ch5 binaries/libraries and ch6 binaries/libraries

True, but that information is irrelevant in the context of analysing the
reproducibilty of the overall build. If you don't see that, then it seems
you're not really getting the point of the ICA.

> /tools is a scratch migration area, the tools are updated and should
> function identical to our ch6 ones but there is always a possibility
> in future that they could become "tainted", they are still built
> outside the chroot so should be considered "semi-trusted"...

Anything is possible! :-)  But luckily we have anal types like us who go
to ridiculous lengths to analyse/design/verify the overall build :-)

PS - actually, the more I think about it, the more I realise there will have
to be exceptions to the rule if Ch 6 is alpabetized. For instance, any
libraries that are linked against by other packages e.g. zlib and ncurses
(as opposed to libraries like the gettext, shadow and e2fsprogs ones) will
need to come very early in Chapter 6, probably straight after gcc, similar
to where they are now.

More information about the lfs-dev mailing list