Installing the Distro
jrhodes at roket-enterprises.com
Thu Jul 15 17:53:44 PDT 2010
Actually Michael, AppCompile (part of the AppTools suite) already compiles
applications within a sandbox. Sounds like I've got the solution to your
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.
On Thu, Jul 15, 2010 at 2:24 PM, Michael Shell <list1 at michaelshell.org>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!
> Mike Shell
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the blfs-support