Status of the repository

Jeremy Huntwork jhuntwork at
Wed Sep 21 11:56:37 PDT 2005

Alexander E. Patrakov wrote:
> Hello,
> the status of the Live CD repository is rather bad.

My account will be deleted likely tonight and I won't be subscribed any 
longer to this or other LFS lists, at least not for some time to come. I 
did however want to reply to this.

First off, apologies for the bad state of the repo. My decision came in 
the middle of several changes I was working on.

> 1) glibc instructions in trunk match none of the available books

Only for the reason that the other archs (sparc and ppc so far) were not 
doing well on the patched 2.3.5 glibc (I thought x86_64 might give some 
trouble as well, but I don't know this...) and I hoped that the LFS book 
would soon change.

> 5) commands, visual effects and logging are not clearly separated in 
> Makefiles. As a result, it takes more than one 80x25 screen to compare 
> the commands in the Makefile and in the book

Yes, I very much wanted to see this cleaned up and organized a bit better.

> 6) downloading of the SVN book to /usr/share/LFS-BOOK is broken

Yes, I was aware of this one, it was on my personal todo list.

> 7) unionfs is still used, although device-mapper solution is already 
> tested, but even it is in fact unnecessary in the utf8 branch: any 
> reason for the need to write to /usr is a bug, and the font-related 
> reason is resolved there by avoiding non-Xft based apps.

It can still be useful to have /usr writable as I found when working 
with CD's containing a broken /usr/bin/net-setup script. And I'm sure 
that other situations might come up.

I will say that my impetus for a *lot* of my decisions lately was so 
that it would be relatively easy to produce working and similar LiveCDs 
on various archs. To that end I strongly oppose any use of modules for 
the root filesystem. Everything (drivers, whatever) the initramfs init 
needs should be built into the kernel.

Also, it's my opinion that the proposed devmapper setup unnecessarily 
complicates matters. The latest unionfs is a *lot* more stable than 
other recent versions and they've recently pinpointed some other vfs 
related issues that they feel will further increase the stability of 
later versions.

Using unionfs in this way along with a very simple C-based init greatly 
reduces the complexity of the CD and makes it much easier to achieve 
similar results on various architectures.  Also, the init.c I've just 
written makes it very easy to identify the LiveCD using the ISO volume 
ID string without having to download and build klibc and isoinfo.

I urge you to consider carefully in this matter concerning using 
devmapper - be careful not to create an overly complicated setup.

> This cleanup resulted in more easily readable/verifiable commands and 
> freed me from thinking about logging in each package's Makefile. 
> However, committing this will result in a 300KB message and inability 
> for me to merge things to/from trunk (but since Jeremy Huntwork said 
> goodbye, that isn't a big problem). Also I am going to remove sha1 sum 
> checking because of frequent (apparently bogus) mismatches (e.g. on 
> make-3.80). Do you want this cleanup?

What you've done in the functions file is nice.

Anyway, I hope you take the above into consideration.

All the best,


More information about the livecd mailing list