[gentoo-dev] BUILDROOT concept (was Re: [gentoo-dev] ROOT variable)

[Paul Smith]

I know this is long.  Hopefully it's sufficiently interesting to justify
the length :).  Hopefully some of you can find the time to wade through
it.


%% Chris Gianelloni <wolf31o2@g.o> writes:

  >> Looking the code, it's looking for _BOTH_ /var/cache/edb _AND_
  >> $ROOT/var/cache/edb.

  cg> I would think that is correct, to test for both DEPEND _AND_
  cg> RDEPEND.  The stuff in DEPEND would need to be in your REAL /,
  cg> whereas RDEPEND would need to be in $ROOT/.

So, I've been looking at the latest CVS Portage code, especially in
emerge, and I think I've much more completely grokked the distinction
between "/" and ROOT, and DEPEND and RDEPEND now.

It's become obvious to me that these distinctions aren't going to
satisfy my requirements, unfortunately.

I believe now that these capabilities really are solving a subset of the
entire problem space, and my requirements are for a fully realized
solution.

What I want to be able to do is this: have one (or more) Portage
installations, or "images", on a system.  An "image" is a complete
Portage system, but "virtualized" by having it rooted somewhere besides
/.  Suppose you had a directory like /opt/portage, and under there you
had p1, p2, p3, etc. which were Portage images.  Then underneath each
one of those would be, for example, an etc/portage directory, and a
var/log/emerge.log, and a var/db/pkg, etc. which contained Portage
control files/databases for only that image.

Now when you want to install a new package, before you can run emerge
you need to choose a "build", or host, image and a "destination", or
target, image.  We'll say that the destination is selected by the value
of ROOT, and the build image is selected by the value of BUILDROOT.


Obviously the simplest case is where both ROOT and BUILDROOT are "/"
(which would be the default value).  This represents the standard
Portage usage.

Another situation would be where BUILDROOT is "/" and ROOT is something
else.  This is sort of represents the capability Portage has
today... but not quite (see below).

Then the most generic case would be where both values are set to
something other than "/".  In this situation the "real" system might not
really be consulted at all: all the build tools: compilers, linkers,
bison/yacc, etc. (including Portage itself!) would be installed in the
"build" image, with all the stuff that is built being put into the
"destination" image.

The idea is you could create new Portage images quite independently from
your real system.  In particular, the new Portage image could be for a
completely different architecture: cross-compilers could be installed in
the "build" image, then used to build and install into the
"destination".


The above is not such a big deal; it could play relatively nicely I
think with the current Portage.  We just need to change references to
fully-qualified paths with variable-qualified paths based on the
BUILDROOT value.


However, the problem of the current handling of DEPEND vs. RDEPEND is
not so simple to resolve.  It looks like DEPEND and RDEPEND are targeted
at a very different scenario than the one I outline above.  If ROOT is
set, it appears that Portage looks for DEPEND packages on the "real"
system and RDEPEND packages in the ROOT image.  Also, all the Portage
database info, logs, etc. is kept in the "real" root, not the ROOT root.
I guess I'm not quite clear on what scenario this setup actually
supports?  Can anyone give me a quick use-case?  It almost seems like
you're trying to support creating non-Portage-based images from a
Portage-based image... that's not something I'm really that interested
in.

One way I could understand this distinction being used is with binary
packages: if you're installing a binary version of a package then you
need to only check that its RDEPEND packages are installed, not the
DEPEND packages, since it's already built.  But, I don't think that's
how it's intended to be used based on what I see.


In my environment the above would not be correct: both DEPEND and
RDEPEND packages would have to appear in the ROOT image (remember that
the BUILDROOT and ROOT could be completely different architectures!)


For my purposes I might need a different kind of depend, call it a
"build DEPEND" or BDEPEND.  This would be a set of packages that are
needed in the BUILDROOT image in order to build the ROOT image.  It would
only contain host-based tools, I guess, that were needed for building:
as above it would refer to compilers, cross-compilers,
bison/yacc/lex-type tools, etc.  This would be very cool, but maybe not
critically important.


SO!  Does any of that make sense?  Is there some way we can rationalize
the handling of DEPEND/RDEPEND?  Maybe something like if BUILDROOT is
set then DEPEND/RDEPEND are both looked for in the ROOT?  I don't really
like that as it seems like "special magic" that's kind of difficult to
understand, but it is backward-compatible.

-- 
-------------------------------------------------------------------------------
 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