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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
