gerard at linuxfromscratch.org
Wed Feb 27 14:46:23 PST 2008
Package Management is a complicated subject to discuss. Nobody really
agrees on what a package manager is supposed to do beyond its very basic
function: able to uninstall an installed package and vice versa.
Dependency conflict resolution is often thrown in as well.
You can't truly talk about package management without talking about an
automation process (ALFS in our world) that does the actual work of
resolving (or at least informing of) dependencies, their conflicts, the
installation and removal jobs.
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.
It's by no means a good system but it's how it all starts. Those are a
few commands (or a script we have users create to partially automate the
repetitious commands) we can add to every package installation in the
book and call it done.
There are so many directions we can now take to enhance this into an
actual package management process. The more we will talk about this, the
more we will actually be talking about ALFS and less about core Package
Management (PM). The lines between ALFS and PM will blur and the terms
will be used interchangeably.
We first need to develop an understanding where LFS and PM meet and move
forward. It will determine our other goals - better and more seamless
integration of projects like ALFS and BLFS.
More information about the lfs-dev