Re: [gentoo-alt] [prefix] Different install and build path

[Fabian Groffen]

On 08-11-2007 14:18:54 +0200, Dirk Heinrichs wrote:
> Am Mittwoch, 7. November 2007 schrieb ext Fabian Groffen:
> > On 07-11-2007 17:28:04 +0200, Dirk Heinrichs wrote:
> > > Hi,
> > >
> > > I just found out about the prefixed portage project. Looks like it
> > > finally implements functionality I requested already two years ago.
> > > That's good news.
> >
> > My memory is bad, what in particular were/are you looking for?
>
> See background below.
>
> > > What I would like to know is the following: Would it be possible to
> > > build for one prefix, but install into another?
> >
> > I'm not sure if I get what exactly it is that you want, and I'm not
> > familiar with AFS (sorry Stefaan ;) ), but it looks a bit like
> > automounted stuff, and in particular the BSD automounter's scheme.
>
> No, it's far superior than that. It creates a global directory tree
> under /afs. The clients only mount /afs, the tree is assembled on the
> servers. Volumes are created on the servers and mounted into the tree
> somewhere, making them instantly visible on the clients. Volumes can be
> replicated (ro) for higher availability. However, if a ro replica of a
> volume exist, the client always prefers it over the rw replica, unless the
> path to the rw replica is used explicitely.
>
> And that's the problem I want to solve. Install software into a different
> path than it was compiled for, automatically. Plus, after installation of
> each package, release the volume (replicate the changes to all ro
> replicas).

In a way what you ask for is impossible, and can only be hacked around.

The actual problem you have, is that your afs setup basically prevents
you from "doing things right".  The path of the ro replicas, which is
the path your clients use, should match your EPREFIX, for the simple
reason that things like library deps are looked for in EPREFIX.

Installing into another location basically means a sort of what portage
does before it merges the package, in $D the image dir.  If you apply my
binpkg trick I wrote about before, you run into trouble as the EPREFIX
is actually changed, making the software useless for the ro replica
clients.

I looks like you can either hack with ROOT support a symlink pointing to
your rw location.  This however, has some side effects, because ebuilds
in general consider certain tasks not to be performed when $ROOT != "/".
Additionally, this assumes that EPREFIX is set up in such a way that the
rw mount point can actually have a full EPREFIX in it.  This is not the
case with the example you gave (a dot in the second dir from the root).

Since I don't feel like hacking afs release volume support in Portage --
it feels way to specific, and far beyond the task of the package
manager, I think it is much better to have a special build machine,
which some special setup, that basically does something like this:

(I have no clue if something like this was implemented:
http://osdir.com/ml/linux.gentoo.portage.devel/2004-12/msg00047.html
You might, however, be able to trigger some stuff via
etc/portage/bashrc)

a) modify the image before installing (this will upset portage a lot)
b) create a binpkg, extract it, copy to the path for the rw volume, run release script

Portage can also --buildpkgonly which means you can just emerge with
EPREFIX on the ro volume, but Portage never trying to install the
package, instead leaving the binpkg behind.  I guess some clever
scripting around this with option b) in mind would be able to do most of
the stuff you want.  I could even imagine when you set PKGDIR to a rw
volume and have one server periodically look for new files installed
there, that you can "autodeploy" anything emerged by any client this
way.  There would only be a little delay between the actuall merge
completion and the deployment of the package.

Does this help?


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-alt@g.o mailing list