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

[Paul Smith]

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

  pdv> On Friday 23 April 2004 21:45, Paul Smith wrote:

  >> It does _NOT_ change where DEPEND packages are searched for:
  >> they're still searched for on the native system not in the ROOT
  >> system.  If the native system and the root system are very
  >> different, that doesn't seem like it can work properly.

  pdv> No it will probably not. You must understand though that adding
  pdv> something to DEPEND only tells portage that that package should
  pdv> be available, but it does not change the build process or it's
  pdv> native checks. As such the package itself searches for headers
  pdv> and libraries in the root directory.

Certainly, but that's just a straightforward (heh! :)) cross-compiler
issue: that's been a solved problem for years--not in Gentoo or Portage
maybe, but in development communities.

In this discussion I'm more concerned about issues specifically related
to the way Portage itself is structured, not how the compile commands
that ebuilds work.

  >> More generally, what I want to be able to do is build for a target
  >> (ROOT) a specific set of packages and versions _without_ having to
  >> modify my physical system in any way.  I don't want the build of the
  >> ROOT to have any relationship to what I have installed on my physical
  >> system.  If I want ROOT to have a version of a package that doesn't work
  >> with a newer version of GTK or whatever, I don't want to have to
  >> downgrade the version on my physical system in order to build that
  >> ROOT.  Maybe I want to create a ROOT system with a KDE desktop but don't
  >> want KDE installed on my build system.  Etc.

  pdv> That is not possible, the only way to do it is with a chroot jail
  pdv> such that you create a similar environment.

No; it certainly _IS_ possible.  I'm doing it today, although I've had
to do some hacking to Portage to get it to work.  I'd like to see some
of my changes move into Portage to allow it to become more flexible and
to decrease the extent of my hacking.

As you point out, there is some work required to get the compiler to
find the things in the correct places, but again this is just the norm
for any cross-compiler setup so it's not any extra work.  We have a
shell wrapper in front of gcc and g++ which sets things up based on an
environment variable rather than hardcoded pathnames.


Chroot is not an attractive option for me.  First, it's confusing in a
cross-compiled environment; you have to install a complete _HOST_ setup
in the _TARGET_ image (since that's where the chroot will leave you) so
that you can run the cross-compilers: you need a HOST glibc, ld.so,
etc. in the target image for use during the compile, as well the normal
target glibc, ld.so, etc. so it's difficult to set up either way.  Also,
it requires root privileges which raises its own set of concerns in some
circles.

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