Re: [gentoo-dev] Creating multiple "installations" on the same host

[Paul Smith]

%% Paul de Vrieze <pauldv@g.o> writes:

  >> Are these supersets of each other or can they be disjoint?  In
  >> other words, if I have a library package contains header files,
  >> which are build time dependencies, and shared libraries, which are
  >> both build and runtime dependencies, should I declare both DEPEND
  >> and RDEPEND?

  pdv> Yes.

Good to know; thanks.

  >> In the above example that package is a DEPEND... but it will be
  >> installed under ROOT, not under /.

  pdv> If it is not in RDEPEND (which most compiletime dependencies are
  pdv> with the exception of things like autoconf/automake etc.) that is
  pdv> a bug and should be filed.

OK, I think I begin to see the intent behind ROOT, and I don't think it
is flexible enough for what I am looking for.  Admittedly, what I'm
looking for is probably fairly unique :).


ROOT appears to allow someone to create a different installed area, but
it still requires that all the software required to build that installed
area reside on the base system (everything that is in a DEPEND
line--which is virtually everything!)

This isn't what I'm looking for, actually.  I want to be able to build
an install area with complete freedom from my "real" desktop.  I want to
build with completely different versions of all sorts of tools than the
ones on my "real" system, without having to install them on my real
system.

In fact, I want to be able to do it without even being root!


What I would be interested in seeing is a new variable, like BUILDROOT,
that could be set to something other than "/".  This value would be
prefixed to any path that looked at the build system rather than the
install system.  This is basically how we do it except our code is not
clean either--instead it forces ROOT into the role of my suggested
BUILDROOT above, so it serves both roles.

Then, if people wanted a 100% divorced install they could set
BUILDROOT==ROOT==something besides "/".  As a result, nothing on the
"real" system (well, except for things like sh and python to run the
Portage tools themselves--which is OK) would be used.

This is how we use Portage actually: we first create a "host" image
which contains all the build tools (cross compilers, build system,
Portage itself, etc.)  Then we use that "host" image to generate the
other images.  In this way the entire environment can be created with no
special privileges or access, and without impacting the contents of the
"real" system at all.


The other change I would like to see is a way to avoid the requirement
for root access.  These extra "images" I'm creating don't need to be
installed as root, because I'm creating them in my own area.  Not only
that, but if there's a personal BUILDROOT then even _THAT_ doesn't
require root access; it could also be an image I've built myself.

In that past when dealing with permissions I've had good results using
an idea taken from UNIX's sticky bit: instead of requiring the user to
configure some account you just use the owner of the upper directory and
apply that to the contents.  In this situation, we would find the owner
of the ROOT and/or BUILDROOT directories and use that as the required
owner instead of hardcoding "root" in Portage.  Obviously a little bit
of logic has to enter in here: if the owner of either ROOT or BUILDROOT
is root then you must be root; if the owner of neither of them is root
then they must be the same.  Another safety measure might be that if
either was "/", then you have to be root (just in case someone
accidentally chowns their "/" directory).  For example.


I'm willing to supply patches for these things if it seems like
something people are interested in.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@××××××××××××××.com>   HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.

--
gentoo-dev@g.o mailing list