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