On 25-11-2009 16:43:32 -0700, Denis Dupeyron wrote:
> Things seem to be progressing nicely on this front. We have answers to
> the questions people had and they look satisfactory to me.
>
> One thing that I think would be valuable is a document that explains
> the average dev how to make his/her ebuilds prefix compliant with
> links to more details when necessary. I understand that there's the
> trivial situations and the less trivial ones. In the latter case it
> would be nice to explain why the case isn't trivial and how to fix it.
> Using python as an example could be one way to do it. I'm thinking of
> something practical that could possibly be patched into devmanual. If
> such a document already exists then please just point us to it.
I'm working on a PMS patch at this very moment. I hope to finish a
first version today.
The Python ebuild is a very bad example, IMO. Not that the style there
is horrendous or something, but more that a couple of things are mixed
up in there, which are not directly a Prefix issue, but a derivative of
that -- support for arches which cannot be supported without Prefix.
We can explain some cases though. The *blas-* family comes to mind as
we recently had to alter them for Prefix.
> > Next to that, it is part of the Prefix team's job to make sure that
> > whatever is installed, does not reference the host system when this is
> > not absolutely necessary.
>
> Could you give some examples of when it is absolutely necessary?
Simple example is perl. If you install a script, for instance ekeyword,
then it is important that this script doesn't say '#!/usr/bin/perl' in
its shebang. "/usr/bin/perl" may simply not exist, but more importantly
it is not the perl that Portage has installed and also installed all
required dependencies for. Hence, ekeyword should be installed such
that it references the perl from the offset installation, e.g.
"/home/joe/gentoo/usr/bin/perl".
"/bin/sh" is another nice one. Technically this should work fine, as
almost every system has this shell available, however in practice it
won't work that well, because many people assume that "/bin/sh" is a
POSIX shell, which is not true on every UNIX that exists, as far as I
know. People may also rely on things from the Gentoo environment in
such scripts, which of course are not present in the host provided
"/bin/sh", hence also here we need to call "/home/joe/gentoo/bin/sh"
(for the chosen offset-prefix "/home/joe/gentoo").
Outside scripts, also libraries have this same principle. An
application linking against libexpat should do so against the Prefix
installed version of expat. If the host system provides
"/usr/lib/libexpat.so" and the upstream configure script is hardwired to
look in "/usr/local/lib /usr/lib64 /usr/lib32 /usr/lib /usr/sfw/lib /sw"
it will never find libexpat from "/home/joe/gentoo/usr/lib". In such
case either an --with-expat="${EPREFIX}"/usr option needs to be passed
to configure (if it exists), or if nothing possible configure be hacked
not to use this hardwired list of paths, but instead fall back on the
default, which for a Prefix toolchain includes the offset library search
paths before the host system's. In any case, it must compile and link
against the Prefix installed libexpat, since the one from the host
system usually is very archaic and not under Portage's control.
--
Fabian Groffen
Gentoo on a different level
