Installing the Distro

James Rhodes 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
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 <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!
>
>
>  Cheers,
>
>  Mike Shell
>
>
> --
> http://linuxfromscratch.org/mailman/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/blfs-support/attachments/20100716/2c2bb5ce/attachment.html>


More information about the blfs-support mailing list