Onward branch

Jan Dvorak jan.dvorak at sitronicsts.com
Tue Aug 26 00:00:00 PDT 2008

On Tuesday 26 August 2008 07:40:42 Robert Connolly wrote:
> I'm planning to start a new branch (like Neo), in plain text, named
> Onward. Before hlfs was xml it was in text, and pages worked as shell
> scripts. The pages can be read, or run as shell scripts, to install
> packages. I'm sure there is a way to convert the plain text book into
> simple html, wiki, or whatever.

Sounds good.

> Furthermore, the chroot system will be replaced by a reboot. This will
> eliminate host system requirements for the final system... Glibc test
> suites will all pass, livecd maintenance can be covered by the
> temporary system, kernel version and capabilities module would not be
> an issue on the final host system, the host of the final system can be
> trusted, etc.

Still good.

> An html viewer (web browser) will not be needed because 
> the book is usable as shell scripts. The 'more' program is enough to
> read the book, but users can certainly install whatever text file
> reader they choose to /tools. An sshd daemon (dropbear) will be needed
> in the temporary system for remote installs.

You are making me anxious. The only reason why I haven't built HLFS was 
that I did not have enough time to copy & paste all that text and watch 
it build. No simple *working* automation.

> Boot scripts will need 
> some modifications to use /tools/bin. A second reboot will not be
> strictly needed.

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 

> This new build system will need a lot of testing, but I feel this
> system is necessary to escape some of the issues with hlfs's
> dependencies.

I have access to several IBM blades... 2x quad-core Xeon + 8G RAM, SAS 
disks. I need them installed, but I can always use KVM and run automated 
build and then run some kind of test suite, if you make one.

> This new branch will be glibc with linux26. I think all hope of using
> linux24 is lost, unless we downgrade to glibc-2.3.6. uClibc will be
> returned asap, but it may take a while.

Bye, bye 2.4. That took a while. ;]

> 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 

Looking forward to hear about this nice transformation soon,


More information about the hlfs-dev mailing list