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). For most packages you can do 'make DESTDIR=/tmp/package install' and the tree will be installed there. Doing a ls -R /tmp/package gets you the list of filenames. One problem with this is that some files get modified, not replaced. 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. That's really hard. Many libraries have no idea what packages use their functionality. The same can be said for utilities like sed, grep, etc 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! But what is the alternative for most users? If you just want to use a system, you want the dependencies to be taken care of for you. The installation and upgrade process is inherently complex. When you get packages from multiple sources the probability of breaking something is really quite high. In some cases, the only real solution is to reinstall everything. LFS actually gives the most flexibility of all, but the upgrade path for a package is usually installing over the old package. Most of the time that's ok. It does leave some breadcrumbs around, but usually they are not significant. One of the reasons I use /opt for things like qt or kde is so I can upgrade to a new package without blowing away the old one. I really don't know of any regular distro that allows that. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
