1 |
Recently, Prefix changes have been committed to the gentoo-x86 tree, it |
2 |
was rather ambitious on my part, where I moved stuff that we are not |
3 |
maintainer of ourself. It should have been communicated better for |
4 |
these ebuilds. This is a formal apology for springing that onto you. |
5 |
This will attempt to solve the confusion and answer questions that have |
6 |
been raised. |
7 |
|
8 |
Gentoo Prefix has mainly the following characteristics: |
9 |
- allow for unprivileged installations, |
10 |
- in an offset-prefix called "the prefix", often referred to as EPREFIX, |
11 |
in autoconf words: ./configure --prefix=${EPREFIX}/usr |
12 |
|
13 |
In the Prefix Portage branch, that we have in use [1], we extended and |
14 |
adapted regular Portage to support above two characteristics. I will |
15 |
ignore the details of unprivileged installations in this email. |
16 |
|
17 |
The offset-prefix changes in Portage introduce three new variables that |
18 |
are available in the ebuild environment: |
19 |
- EPREFIX: the configured offset-prefix |
20 |
- ED: shorthand for ${D%/}${EPREFIX}/ |
21 |
- EROOT: ${ROOT%/}${EPREFIX}/ |
22 |
|
23 |
The offset-prefix changes require extensive changes to most eclasses, |
24 |
and minor changes to many ebuilds. This is mainly because "awareness" |
25 |
of the offset-prefix has to be added to places where ebuilds manually |
26 |
deal with file-system locations. In particular: |
27 |
- configure calls that specify some argument to find a component need to |
28 |
do so in the offset prefix, e.g. |
29 |
--with-libxml2="${EPREFIX}"/usr/$(get_libdir) |
30 |
- almost every place where ${D} is used, the offset-prefix ${EPREFIX} |
31 |
has to be added. Because this is lengthy, Prefix Portage provides a |
32 |
variable ${ED} that is the shortcut for ${D} plus the offset-prefix. |
33 |
- the same holds for occurrences of ${ROOT}, where ${EROOT} is available |
34 |
as shortcut |
35 |
|
36 |
Why do we need both ${ED} and ${D}? Technically we don't, because we |
37 |
can use ${EPREFIX} all the time. However, one cannot say that ${D} |
38 |
includes ${EPREFIX} for Prefix Portage, because that means the following |
39 |
src_install() function no longer works correctly: |
40 |
|
41 |
src_install() { |
42 |
emake DESTDIR="${D}" install || die |
43 |
mv "${D}"/usr/bin/{,exuberant-}ctags || die |
44 |
} |
45 |
|
46 |
While the "mv" does a great job if ${D} would include ${EPREFIX} here, |
47 |
the make install will cause double offset to be written, since configure |
48 |
recorded the ${EPREFIX} before in src_compile using the argument |
49 |
--prefix="${EPREFIX}"/usr. In a previous version of Prefix Portage, the |
50 |
variable EDEST was available as workaround for this, so the example |
51 |
would read like this: |
52 |
|
53 |
src_install() { |
54 |
emake DESTDIR="${EDEST}" install || die |
55 |
mv "${D}"/usr/bin/{,exuberant-}ctags || die |
56 |
} |
57 |
|
58 |
Apart from that this approach got very tricky and confusing in eclasses |
59 |
and ebuilds that do special mungling in their src_install, it makes it |
60 |
harder to reconstruct the variable in normal Portage and hence to make |
61 |
existing ebuilds forward compatible. |
62 |
|
63 |
The lengthy forward compatible version of the example src_install |
64 |
function would look like this: |
65 |
|
66 |
src_install() { |
67 |
emake DESTDIR="${D}" install || die |
68 |
mv "${D%/}${EPREFIX}"/usr/bin/{,exuberant-}ctags || die |
69 |
} |
70 |
|
71 |
As mentioned before, this is pretty lengthy, and quickly becomes too |
72 |
much work and unreadable when ${D} is used more. |
73 |
To avoid the confusion that implicit ${EPREFIX} in ${D} in the ${EDEST} |
74 |
approach brought, ED and EROOT were chosen because they are easy to |
75 |
understand and easy to reconstruct outside Prefix Portage. To help |
76 |
with this, the Prefix profiles use.force the "prefix" USE-flag. |
77 |
Non-Prefix profiles have this flag masked and unset in the base profile. |
78 |
This USE-flag can be used to do conditional code for Prefix consumers. |
79 |
In case of our ${ED} and ${EROOT} convenience variables, we can use it |
80 |
to define ${ED} and ${EROOT} in case a normal Portage is used. For our |
81 |
example function: |
82 |
|
83 |
src_install() { |
84 |
use prefix || local ED=${D} |
85 |
emake DESTDIR="${D}" install || die |
86 |
mv "${ED}"/usr/bin/{,exuberant-}ctags || die |
87 |
} |
88 |
|
89 |
Here, Prefix Portage (using a Prefix profile) will not set ${ED}, but |
90 |
still do as intended because ${ED} is set correctly by Prefix Portage. |
91 |
Normal Portage will set the convenience variable such that it does not |
92 |
cause a sandbox violation due to the missing image path. |
93 |
|
94 |
We will consult the maintainers of packages we would like to make |
95 |
compatible with Gentoo Portage before adding the changes. In the |
96 |
future, you will likely see more bug reports and more requests on IRC |
97 |
from us. |
98 |
|
99 |
At this point, we have reached a critical mass where we cannot maintain |
100 |
the Prefix overlay much longer with its size and usage. We either |
101 |
continue to grow on, requiring less maintenance on tree synchronisation, |
102 |
or we stop the project -- an option we really don't like. |
103 |
Bringing back most, and ideally all, ebuilds to gentoo-x86 significantly |
104 |
improves the workload caused by synchronisation, leaving more time for |
105 |
the real issues. Examples are fixing and porting packages and getting |
106 |
the Prefix Portage branch merged with regular Portage some day. At that |
107 |
point, the variables EPREFIX, ED and EROOT can become available in a |
108 |
next EAPI as well. |
109 |
|
110 |
|
111 |
[1] http://sources.gentoo.org/viewcvs.py/portage/main/branches/prefix/ |
112 |
|
113 |
-- |
114 |
Fabian Groffen |
115 |
Gentoo on a different level |