On Wed, 15 Aug 2007 00:02:07 -0400
Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Hello,
>
> As I've been giving some thought to what might make the LiveCD
> project more manageable, more open to community development and
> better all around, it occurred to me that our build method could be
> adjusted. Right now the build is automated by a long series of
> Makefiles that was, in some respects, the inspiration for jhalfs. You
> set some variables, run make, wait 6 hours or so, and voila!
> (hopefully) a LiveCD. It gets very difficult (or, at least, annoying)
> to develop because of the long times involved in building the entire
> thing.
First up, I should say that until yesterday I didn't use the LiveCD, I
had one (from long long ago) but it was curio. I build the next LFS on
the old LFS... Yesterday my friend gives me his old laptop - I'm
looking for a zero-cost zero-fan replacement for my router, and I need
LFS on it quickly. I downloaded the 6.2-5 image and was up in am hour
- it even correctly detected the pcmcia lan card, and the xorg.conf
was spot on. Note also that neither fedora-6 nor ubuntu-7 would have
anything to do with this box. So I'm impressed. (and I'd like to see
instructions for loading the precompiled image onto the HD and making
it bootable - I can do it, but then...)
> So an idea is brewing...
>
> Essentially, the LiveCD is a distribution. But it is a distribution
> without something that nearly all others have: package management. Up
> to now, there hasn't really been a need. But, if the CD incorporated
> PM at its very heart, developers could focus more on tightening
> individual components instead of always building the entire CD in one
> shot.
If the LiveCD build process has a package manager, then 'ipso facto', so
does {b}lfs.
> For example, let's say a flaw was found in one of the pieces of
> software included on the CD. With the PM incorporated into the build,
> all we would need to do is grab the latest packages, run a small
> script to install them into a working directory with the proper
> configuration, update the build commands for the package in question,
> rebuild it, re-package it, and re-release an ISO. Working in this
> method should shorten build times, help solidify the build, and open
> up a host of other possibilities.
A package manager doesn't absolve you from regression testing. It just
makes it easier to get the thing built. The Live CD, almost more than
the Book, needs to work for a big proportion of those that try it.
> If you like the sound of this new approach, please share your
> thoughts on what might help make it work. Details need to be
> discussed, such as the exact development model, package management
> tools, updated development scripts, tracking dependencies and
> standards for development. I'll wait until there is some discussion
> before I speak any further on some of the details that are already
> forming in my head.
If you use some little odd-ball PM, rather than, say RPM you will end
up spending more development effort on the PM than on the LiveCD.
Frankly, I think we should have a PM in LFS, indeed it MIGHT be
good to build LFS as a distribution - so that you end up, not with a
partition to boot, but with an LiveCD that has an Install application.
> Lastly, I'm posting this to {,b}lfs-dev because I'd like to make sure
> those current groups of readers have the opportunity to comment. If
> possible, though, please send discussion to the livecd list.
Can't use LiveCD list, it's not on gmane. Let's try and get it on
gmane, shall we? The arch-hives are the important thing.
R.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
