An idea for a new development model

[Jeremy Huntwork]

Jeremy Huntwork wrote:
> And for that reason I think I would be against adding a specific PM to
> LFS/BLFS. However, dropping in a DESTDIR framework would allow for
> *most* package managers to be used without adding any further specifics.
> 
> At this point, whether or not LFS or BLFS decide to use DESTDIR (or
> anything else) isn't as important to me as getting the proper setup in
> place for the LiveCD. :)

OK. Here are some more details that have been rolling about in my head 
as to how LiveCD development might proceed. Thoughts very welcome:

  * Temporary tools a la LFS chapter 5 produced and stored on 
kerrek.linuxfromscratch.org. I can set this up to be done automatically 
whenever there is a change to chapter 5, or chapter 5 package versions. 
This gives us a nice place to start from.

  * Packages and their build logs also reside at kerrek. Developers 
preparing to work on the CD could perhaps make use of rsync to update 
their local working area before starting any software builds.

  * Config.site is employed to ensure a consistent environment when 
building. For x86, all pieces of software should be targeted at i486. 
Also, as much as possible, we stick to LFS build methods, order and 
versions for the version of LFS book at which the CD is targeted.

  * Tracking Dependencies. There's much to discuss here. First of all, I 
can't recall from pkgtools, but does Pacman help track dependencies 
similar to RPM? That may be one advantage of making use of RPM. Whatever 
package manager we use, we want to be able to track how packages are 
affected. My hope is to avoid as much as possible, the long builds of 
the CD that we currently have, and to make the production of the CD a 
simple matter of installing the system to a working directory using 
pre-built packages and rolling up an ISO. So, if for example, there is 
an updated version of Openssl, we'll want to know what packages link 
against it so that those can be built against the new version. It would 
be nice if we had a system whereby we can flag one package for update, 
and all those after it in the dependency tree would be flagged as well. 
Is this making sense?

  * Lastly, we need to write recipes in the form of scripts that will 
properly set up a working environment, grab the necessary binary 
packages, install them and create the ISO.

I'm still having some trouble seeing exactly how much of this will take 
shape. Hopefully the above will spark some other ideas and discussion.

--
JH