| 1 |
On 08-11-2007 17:05:57 +0200, Dirk Heinrichs wrote: |
| 2 |
> > In a way what you ask for is impossible, and can only be hacked around. |
| 3 |
> |
| 4 |
> Hmm, is it? In the end, what I ask for is the portage equivalent of: |
| 5 |
> |
| 6 |
> configure --prefix /afs/mydomain.com/software |
| 7 |
> make |
| 8 |
> make prefix=/afs/.mydomain.com/software install |
| 9 |
> vos release |
| 10 |
> |
| 11 |
> I admit the last one is the tricky one, which paludis could be able to solve |
| 12 |
> with a user defined post-install hook. |
| 13 |
|
| 14 |
Only if Paludis can overwrite make and emake I guess you could do that, |
| 15 |
but that is very untrustworthy; you'd have to verify (and adapt) your |
| 16 |
hack per ebuild. |
| 17 |
Also, doing that may screw up some things if libtool does relinking. |
| 18 |
|
| 19 |
> > Installing into another location basically means a sort of what portage |
| 20 |
> > does before it merges the package, in $D the image dir. If you apply my |
| 21 |
> > binpkg trick I wrote about before, you run into trouble as the EPREFIX |
| 22 |
> > is actually changed, making the software useless for the ro replica |
| 23 |
> > clients. |
| 24 |
> |
| 25 |
> Hmm, maybe not, that would depend on wether a particular package has |
| 26 |
> the --prefix compiled in somewhere. To my knowledge only GCC itself does |
| 27 |
> this (in its specs). |
| 28 |
|
| 29 |
Many applications have the prefix built in, for instance to find their |
| 30 |
own configuration files. |
| 31 |
|
| 32 |
> > a) modify the image before installing (this will upset portage a lot) |
| 33 |
> > b) create a binpkg, extract it, copy to the path for the rw volume, run |
| 34 |
> > release script |
| 35 |
> > |
| 36 |
> > Portage can also --buildpkgonly which means you can just emerge with |
| 37 |
> > EPREFIX on the ro volume, but Portage never trying to install the |
| 38 |
> > package, instead leaving the binpkg behind. I guess some clever |
| 39 |
> > scripting around this with option b) in mind would be able to do most of |
| 40 |
> > the stuff you want. I could even imagine when you set PKGDIR to a rw |
| 41 |
> > volume and have one server periodically look for new files installed |
| 42 |
> > there, that you can "autodeploy" anything emerged by any client this |
| 43 |
> > way. There would only be a little delay between the actuall merge |
| 44 |
> > completion and the deployment of the package. |
| 45 |
> > |
| 46 |
> > Does this help? |
| 47 |
> |
| 48 |
> Have to think about it and try out. Thanks. |
| 49 |
|
| 50 |
Alternatively you can "port" Paludis and do it that way. |
| 51 |
|
| 52 |
|
| 53 |
-- |
| 54 |
Fabian Groffen |
| 55 |
Gentoo on a different level |
| 56 |
-- |
| 57 |
gentoo-alt@g.o mailing list |
Archives