I didn't read each single mail (to be honest just the last ones) and I don't know if it was already mentioned but for me I found pacman as my package manager.
Here is a hint which explains how you can install pacman with the temporary system in chapter 5: http://www.mail-archive.com/[email protected]/msg00030.html I'm not finished with my system because of time issues but my experience so far is that it fits very well. Here are my reasons why I want to use pacman: 1. you build your packages from source 2. you have full control of the building process 3. you can (and should) build the packages in a fakeroot environment (sandbox) so no file in the root filesystem can be overwritten. There exist packages where you cannot use make DESTDIR=... install but make root_dir=... install or anything else so package building process fails and you can correct it without any file to be overwritten. 4. pacman stores its package information in plain text files 5. you can specify config files of the package for backup so your config files don't get overwritten by an upgrade or deleted if you uninstall a package for any reason. 6. you can delete files in the package like /usr/share/info/dir and use an install script instead which updates this file. 7. you can split packages like gcc in gcc-libs and gcc if you want some systems without a compiler for any reason. 8. you can build your own package repositories so packages build on one system can be easily used on other systems with the same architecture without recompiling. For example, I'm currently using a virtual machine on my server as a master where I build my packages and keep an repository and the plan is that I can update my packages on my laptop easy with "pacman -Syr" 9. You can install the same package with different versions by prefix them with /opt and giving them another package name, i.e. foo-1.0 in the root filesystem and foo-test-1.1 in /opt 10. If you have some trouble with a package you can look in the archlinux package repository how they build the package and it could give you an idea how you can fix your issue. :) 11. You can have multiple repositories, i.e. stable and testing and put any new package (or version) first in the testing repository and if it seems to work move it to the stable or just switch back to the stable version of the package. So, why not change to archlinux? I think if you have used your own LFS system for a while you don't want to use any other system/distro. I think you know what I mean. :) Christian Thursday, July 15, 2010, 6:47:43 AM, you wrote: BD> Michael Shell wrote: >> >> Forgive me if this is something trivial or otherwise already well known, >> but all I ever wanted in LFS package management is something that watched >> the installation from source and recorded what files were installed and >> where for purposes of later *deinstallation*. >> The idea here being that all installation/upgrades would be done from >> source - true to LFS - but, a simple application could be called to >> deinstall/yank already installed packages either because they are no >> longer needed or prior to an upgrade where the older version (e.g., >> libraries) is not wanted (e.g., if something else breaks on the new >> library without the old that would get upgraded too). >> It would also be really great if there was some sort of "write sandbox" >> where "make install" would be able to read from the root filesystem as >> normal, but any writes would go to a "sandbox" "empty mirror" filesystem >> so that all the installed files could either be packaged or >> copied/installed after human "inspection and approval" (e.g., see what >> it has written/altered before it is allowed to do so). This would also >> be a safeguard against a malicious installer. Thus, final installation >> could be done via a simple "cp -a" (of course, a simple copy could not >> handle any "post" additions/alterations of files). BD> For most packages you can do 'make DESTDIR=/tmp/package install' and the BD> tree will be installed there. Doing a ls -R /tmp/package gets you the BD> list of filenames. BD> One problem with this is that some files get modified, not replaced. BD> For instance /usr/share/info/dir. >> It would be nice to be able to see a list of things that depend on a >> given application/library, but this is optional. And as James said, >> such things should be done with self-contained databases, or even >> better, just plain text files organized using the filesystem. BD> That's really hard. Many libraries have no idea what packages use their BD> functionality. The same can be said for utilities like sed, grep, etc BD> that are used from within a program (like a shell script.) >> FWIW, IMHO, the RPM package manager started out as a good concept, but >> then became so bloated as to be a sick joke with regard to dependencies. >> The RPM package manager is often the first thing to break during upgrades >> and the last to be restored. It is too fragile with regard to what it >> depends on to be able to rely on it when your system is in trouble. Blah! BD> But what is the alternative for most users? If you just want to use a BD> system, you want the dependencies to be taken care of for you. The BD> installation and upgrade process is inherently complex. When you get BD> packages from multiple sources the probability of breaking something is BD> really quite high. In some cases, the only real solution is to BD> reinstall everything. BD> LFS actually gives the most flexibility of all, but the upgrade path for BD> a package is usually installing over the old package. Most of the time BD> that's ok. It does leave some breadcrumbs around, but usually they are BD> not significant. One of the reasons I use /opt for things like qt or BD> kde is so I can upgrade to a new package without blowing away the old BD> one. I really don't know of any regular distro that allows that. BD> -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
