On 27-05-2011 12:33:56 -0400, Christopher Friedt wrote:
> On Fri, May 27, 2011 at 11:59 AM, Jeremy Olexa <firstname.lastname@example.org> wrote:
> > when emerging binpkgs if "build EPREFIX" != "your EPREFIX" - the catch? The
> > build prefix must be longer than then new prefix. I build binaries in a
> > prefix that is 97 characters long, assuming that the average user will pick
> > a shorter location
This greatly reduces the time for a new prefix
> > installation (down to as quick as 5-7 minutes). In my opinion, changing the
> > docs is even less of a solution.
> Good call - there's always a catch though isn't there ;-) Just
> overwriting strings in the binaries sounds like a good idea. Then
> there's also random regular text files too.
It's not too "just overwriting strings" here. See man chpathtool. I
just noticed this manpage is quite out of date, since it uses different
strategies for binary and text files these days.
> Crossdev can be easily patched to work 'properly', and glibc / gcc
> have a bit of spots that need to be massaged, but otherwise it's
> doable (I can say that now that I've had to do it a couple of times).
> So is there any momentum for eprefixed binaries? I.e. something of a
> stage3? It seems like it will always be an ongoing battle, but string
> substitution probably eliminates a large part of that.
We have the default-prefix dir on
Have you considered trying to do cross-prefix stuff (if you need it?)
E.g. building cross target for a different target EPREFIX? You don't
really need it if you're happy with chpathtool, but technically (at one
point at least) you could emerge for a different EPREFIX than the one
portage was built with/for. I'm not sure if this path is tested much
Gentoo on a different level