On Wed, Feb 27, 2008 at 03:46:23PM -0700, Gerard Beekmans wrote: > > For LFS purposes we first need to determine how far we want to take > package management. In its utmost basic form we can provide commands in > the book to collect a list of installed files before and after the > installation of a package. Compare the two lists with a program like > 'diff', some post-processing to clean up the results, and voila, a file > you can later on loop through 'rm' to remove the just installed files.
That is similar to my own package management - I touch a marker, install, then list everything newer than that marker (excluding the build directory and /home). My version has known shortcomings (some header files are older than the marker so they don't show up, other files, particularly in /etc, get updated once I'm into the blfs area) and is not useful for an unthinking "ok, just remove all of these" script. My pm needs are simple - identify where a file came from, and sometimes identify what changed compared to previous builds. As an example, I've rearranged my non-multilib desktop build scripts to try to get the most out of each package, typically by building libraries earlier rather than later, and I'd brought libgsf too far forward (the optional dependency on libbonobo is in BLFS, but I'd overlooked it) and I had to look at my old logs of what got installed so I could identify where libgsf-gnome-1.pc used to come from. Somebody who wants to build on one machine and then roll out the binaries to other machines has very different needs, and I don't see any pressing reason to accomodate them in my own building and testing. Package management (specifically, 'rpm dependency hell') was one of the things that brought me here - now that I know how to build from source, my hatred of mainstream package managers (rpm, apt) has only increased! For people who need a more-featured package management, there are "proper" distros which claim to do this (I say 'claim' because I haven't used them). By "proper" in this context I not only mean "more focus on security updates", but also "has an upgrade path from version n to version n+1" rather than my preferred "time for a new system". Both of these distro-features apply more to BLFS than to LFS itself. Personally, I'm far more interested in building on multiple architectures than in using package managers. I have 4 boxes available to drive my desktop display (and a 4-way KVM, so it's maxed-out ;), but only two of those can run x86 code (one of those also runs pure64, the other runs multilib). I recall interest about extending LFS to 64-bit (having made pure64 work, I now have mixed feeelings about it for general use), but also prejudice against reincorporating ppc in the LFS book. It seems to me that if "the way forward" is the topic for discussion, we should be talking again about how much (or how little) the book should support. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page