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,
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/livecd
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
