I have another solution that might work better for you.... LFS was obviously not designed specifically for package management- to me, it appears that the design of the OS is to teach the builder how to build software, and how to script such builds himself, and thus be an excellent learning tool, at some of the most fundamental levels of the system.
If you find yourself in a situation where you need a fairly basic Linux, with good package management, and you still want to remain source-based, try Gentoo. It's my distribution of choice, extensible, lightweight, and flexible. You will need to learn a slightly modified directory structure, but you get the benefits f a source distro, pkg. management, plus the ability to do pretty much anything binary distros ship with. If you want more info, let me know. I'm not trying to erode the customer base of LFS, but I'm trying to suggest a possible solution that might be a better fit to your needs. -----Original Message----- From: lfs-support-boun...@linuxfromscratch.org [mailto:lfs-support-boun...@linuxfromscratch.org] On Behalf Of Ken Moffat Sent: Thursday, July 23, 2009 3:25 PM To: LFS Support List Subject: Re: choosing a Package Management... 2009/7/23 RaptorX <grapt...@gmail.com>: > And.... > > if you have to choose which of this would be your choice and why: > > --User Based Management > > --Creating Package Archives > > --Tracing Installation Scripts > > --Symlink Style Package Management > Way back when, some of us (well, me at least!) were driven to LFS *by* package management tools. Since then, many of the problems on the support lists seem to come from people using package management. You need to ask *yourself* some questions, then you might have a better idea of what you hope to achieve from package management. But please note that upgrading the toolchain on a running LFS system is not supported. At some point you "will" have to build a newer system. the sort of questions you should be asking yourself include - how long am I going to keep this system ? - do I intend to upgrade a lot of desktop packages ? (server packages don't usually bring the same world-and-his-dog dependency lists) - am I competent to deviate from the book by using package management ? (e.g. individual package users) - what other benefit that ken has ignored am I hoping to get from package management ? I just make a note of what files are newer than just-before the install. That doesn't catch everything (particularly, some headers) and lets multiple packages update the same file, but it fits my needs. I'm far more concerned about knowing which packages link to static libraries from other packages - e.g. for days like today when I upgrade xulrunner and rebuild anything using it (so, I try not to install static libs, and hide those that do get installed), and once I've finished a system I only normally update packages to fix vulnerabilities - extras I want to try out go into /opt and usually get deleted afterwards. Using a package manager to record the innermost details of which packages alter what files can be revealing, but it seems to me that it's a sideshow. People who want to use some sort of package manager to let them upgrade *everything* probably gravitate to arch or gentoo. ĸen -- After tragedy, and farce, "OMG poneys!" -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
