Onward branch

Robert Connolly robert at linuxfromscratch.org
Tue Aug 26 18:00:27 PDT 2008

On Tuesday August 26 2008 03:00:00 am Jan Dvorak wrote:
> No need to use boot scripts. Just add few logins to inittab, let it spawn
> dropbear and reboot. Things like setting console font, activating swap
> and remounting root in read/write mode can wait and be done manually for
> now.

I was thinking today that adding Busybox to the temporary system would be 
helpfull, to get modprobe, /sbin/init, dhcp client, text editor, etc.

Furthermore, an initrd with busybox could remain as a rescue system, so /tools 
is kept after the final installation. This would work best if /tools was its 
own partition, which is not normally mounted. This way nothing is wasted.

For installation, I guess we would do a pivot_root out of busybox/ramfs into 
the temporary system, after mounting partitions and swap.

Does this seem like a good idea?

> > The combined toolchain will probably be dropped, because it doesn't
> > always work... gcc and binutils need to share compatible libiberty
> > libraries, among other things, or else they won't build in the same
> > tree. The combined tree build method is very nice, but it is not
> > flexable enough yet. I want to bump to binutils-2.18, but that doesn't
> > work in a combined tree with gcc-4.1.2.
> What about 4.2, or even 4.3? Are there any reasons why not go for a newer
> GCC?

All of the toolchain could use an upgrade. Binutils and Glibc only seem to 
maintain their last release version, and abandon old ones. GCC maintains 
older releases for a long time. Using old versions of Binutils and Glibc 
means watching their development for bug fixes, and backporting them, and/or 
shadowing a distribution who does this (alt-linux has a ton of bugfix 
backports for glibc-2.5). Kernel versions go either way... some are 
maintained for a long time, and some are not.

In general I think it's a good idea to wait 6 months, for example, before 
upgrading to new releases. This gives everyone else time to discover bugs. 
Waiting longer than that has a risk of using an unmaintained release, but 
tracking distribution backports and patches helps minimize this risk.

And to complicate things some more, each package is unique. Upgrading Binutils 
is usually safe... they tend to be very conservative and take their sweet 
time with final releases (with rare exceptions). Glibc, GCC, and Linux, seem 
to like to live on the bleeding edge and have a lot of fast development, so 
more caution is needed with them, but they have good a good track record. 
It's really hard to say what is the "best" version of each to use.

My gut tells me to stay with the mature versions, except for Binutils... so 
binutils-2.18, gcc-4.1.2, and glibc-2.5 (with bugfix backports). Linux 
versions track whatever grsecurity is with. I'm curious to know the 
statistics on which Glibc version is currently being used, and maintained by 
distributions, the most. New versions are nice, but the majority of the Linux 
world does not use them, so they're not stabilized yet.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20080826/420d1cb9/attachment.sig>

More information about the hlfs-dev mailing list