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