What next? [Was: Re: LiveCD or No LiveCD?]

Alexander E. Patrakov patrakov at gmail.com
Tue Feb 26 08:51:14 PST 2008

Hendrik Hoeth wrote:

> Before I comment on the suggestions below, I should say a few words
> about how I personally use the CD.

Thanks, this information is very valuable.

> Now to the suggestions:
>> * Go back to the drawing board, so to speak. Start a new CD from
>>   scratch that is minimal [...] (For example, as proof of the
>>   soundness of LFS, the CD should strictly adhere to LFS. [...]
> As much as I love LFS, this would IMHO render the CD useless.

So we see at least two non-empty camps. One wants a strictly minimal CD, and one 
wants packages beyond it. The most "democratic" solution would be to make two 
CDs (and that's, in fact, the origin of the talks about package management), but 
we don't have enough developers. You see--packages are like children, one cannot 
successfully care about more than 8 of them simultaneously.

If you want to help, here is a conceptually simple, but long and boring task for 
you. Draw a tree of dependencies between packages on the current full CD in dia 
or anything else that can be easily converted to SVG. For each leaf package that 
you know how to use, write a short document (or a long document, if a package is 
not simple) explaining how to test its basic functionality ("make check" alone 
doesn't count) and old bugs of the present and past, like the "sample.aac" and 
"don't use --with-drm" instruction at 
http://www.linuxfromscratch.org/blfs/view/svn/multimedia/faad2.html. You may 
assume that the test will be run in an emulator such as QEMU, KVM or VMware, so 
instructions to fill the hard disk(s) with arbitrary contents are allowed.

> I adopted the more_control_and_pkg_man.txt hint for my systems a while
> ago and don't want to miss package management anymore. But for the CD
> one would have to think about which system to use. Also the choice of
> the package management system on the CD might affect the choice of new
> users for their package management, if it's visible on the CD. So an
> option would be to use package management but keep all the meta-data off
> the CD when creating the image.

So far, in a fork of LFS, we tried RPM and talked about Slackbuild. Also, the 
external Russian-specific fork of LFS (not by me) uses Arch Build System that is 
like Slackbuild on steroids. The required characteristics are not only the 
ability to produce, install, upgrade, and uninstall packages, but also the build 
process has to be automated, and it would be nice if one could produce more than 
one binary package from one sourve (e.g., package Pidgin, Finch and 
useless-on-a-CD development headers separately).

> And maybe updating the remastering hint on
> http://www.linuxfromscratch.org/hints/read.html with the current version
> from svn.

Hm, aren't they currently the same?

Alexander E. Patrakov

More information about the lfs-dev mailing list