Actually Michael, AppCompile (part of the AppTools suite) already compiles applications within a sandbox. Sounds like I've got the solution to your problem ;)
It's written in Python and you'll need UnionFS-FUSE along with a few other utilities (it'll tell you which ones you need if you don't have them installed). Simply run appcompile in the source code directory and it'll compile it - any parameters you pass it will be passed onto ./configure (currently it only supports ./configure && make && make install build systems, but it will support more in the future). The structured filesystem I explained before, along with AppLink and AppUnlink allows you to yank / deinstall applications out of the root filesystem at any time. This is the system I currently use on my custom build LFS system. Regards, James. On Thu, Jul 15, 2010 at 2:24 PM, Michael Shell <[email protected]>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). > > 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. > > 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! > > > Cheers, > > Mike Shell > > > -- > http://linuxfromscratch.org/mailman/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page >
-- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
