Planning for Cross-LFS/Multi-Architecture 7.x Release

Matthew Burgess matthew at linuxfromscratch.org
Sat Apr 23 11:41:28 PDT 2005


Bruce Dubbs wrote:

> I'm not really in favor of the "generate the book that you need"
> approach.  I makes it much more difficult to compare techniques and
> understand the differences.

So, as MIPS, PPC and others all require different bootloaders, are you 
suggesting that we put all of them in the same LFS book?  I wonder how 
many folks will actually try to install `colo' on their x86 box if we do 
that!

> Most users will not need to use the cross
> compiling techniques, but may want to know the differences and the
> advantages and disadvantages of each method.

On the contrary, I believe they *do* need to use the cross-compiling 
techniques, simply because it further removes the possibilities for 
their choice of host to affect their build.  The cross-compiling stuff 
widens the number of hosts we can build from, and the number of arches 
we can build for.

> The fundamental objective
> of the book is education and generating separate books, while
> technically possible, would not further that objective.

The reverse is also true though.  Too *much* information can lead to 
confusion and therefore lack of understanding/education.

> I'm also concerned by the idea of adding some BLFS packages to LFS
> (openssl, openssh).  At a minimum, it can cause problems if different
> architectures don't update tools at the same time.

Note, I've not looked at the source, but I'd have thought the additional 
packages are all in their own files.  i.e. openssh is in openssh.xml 
whether it is for MIPS, PPC, etc.  Each arch then xincludes that file if 
it needs it.  Therefore a package upgrade is performed in one place and 
seen in all arches at the same time.

> Perhaps a better
> approach is to point to the BLFS procedures and we can add any
> alternative instructions there for different architectures.

If you're willing for that to happen, I'm O.K. with it.

Regards,

Matt.



More information about the lfs-dev mailing list