An idea for a new development model

[TheOldFellow]

On Wed, 15 Aug 2007 00:02:07 -0400
Jeremy Huntwork <jhuntwork at linuxfromscratch.org> 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.