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