Package Management

Ken Moffat ken at linuxfromscratch.org
Thu Feb 28 08:05:23 PST 2008


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



More information about the lfs-dev mailing list