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

[Dirk Heinrichs]

Am Donnerstag, 8. November 2007 schrieb ext 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.

Hmm, is it? In the end, what I ask for is the portage equivalent of:

configure --prefix /afs/mydomain.com/software
make
make prefix=/afs/.mydomain.com/software install
vos release

I admit the last one is the tricky one, which paludis could be able to solve 
with a user defined post-install hook.

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

Yes, that's clear to me.

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

Hmm, maybe not, that would depend on wether a particular package has 
the --prefix compiled in somewhere. To my knowledge only GCC itself does 
this (in its specs).

> 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 is the reason why I didn't ask for this, but only for the possibility 
to define different paths for configure and make install.

> 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

Looks like what paludis provides with its hooks.

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

Have to think about it and try out. Thanks.

Bye...

	Dirk
-- 
Dirk Heinrichs          | Tel:  [phone]
Configuration Manager   | Fax:  [phone]
Capgemini Deutschland   | Mail: dirk.heinrichs@×××××××××.com
Wanheimerstraße 68      | Web:  http://www.capgemini.com
D-40468 Düsseldorf      | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net