1 |
supporting configurations where lib64 or lib32 is a directory will |
2 |
probably require a change in policy and a change in the dev quiz |
3 |
regarding the use of hardcoded lib directories in ebuilds and when |
4 |
einstall should be used. |
5 |
|
6 |
problem #1) with hardcoded references to lib, i have to go and fix each |
7 |
ebuild that does this by hand so that it will work with lib64 or lib32. |
8 |
there are a LOT more ebuilds that do this in the tree than i expected. |
9 |
|
10 |
problem #2) after having fixed ncurses so that it's libdir agnostic and |
11 |
can install into lib64, it was updated to have utf-8 support and that |
12 |
update included some more hardcoded references to lib. this broke |
13 |
ncurses for users with lib64, and there was one bug report where a user |
14 |
was unable to run anything linked against ncurses. so if an ebuild is |
15 |
CONF_LIBDIR aware, -all- references should use this variable (or another |
16 |
one set based on whether or not CONF_LIBDIR is set). |
17 |
|
18 |
problem #3) since econf might set libdir now, it's no longer sane to not |
19 |
set libdir during make install, either by setting it in the ebuild or by |
20 |
using einstall. ebuilds that use econf will have |
21 |
--libdir=/usr/${CONF_LIBDIR} when [ -z "${CONF_LIBDIR}" ] (this change |
22 |
is in the ebuild.sh in >= portage 2.0.51_pre18), so make install will |
23 |
try to install the libraries to the live filesystem if einstall isnt |
24 |
also used. |
25 |
|
26 |
problem #4) since the stable portage doesnt support CONF_LIBDIR and this |
27 |
variable will not be in all profiles even when it is supported, ebuilds |
28 |
that use this variable must default to setting it to lib. note that not |
29 |
all ebuilds will need to even touch this... anything that uses econf and |
30 |
einstall without using hardcoded lib references in the ebuild is already |
31 |
perfect. |
32 |
|
33 |
|
34 |
none of these problems exist when using econf and einstall, and when |
35 |
you're not messing with libs in the ebuild. all the problems can also be |
36 |
avoided in ebuilds that mess with libs by simply using a variable. if |
37 |
there are any instances where einstall cant be used, that needs to be |
38 |
fixed in einstall so that it can be. |
39 |
|
40 |
so... maybe something like this for an ebuild that needs to install to /lib: |
41 |
|
42 |
pkg_setup() { |
43 |
[ -z "${CONF_LIBDIR}" ] && export CONF_LIBDIR="lib" |
44 |
} |
45 |
|
46 |
src_compile(){ |
47 |
econf --libdir=/${CONF_LIBDIR} blah |
48 |
emake |
49 |
} |
50 |
|
51 |
src_install(){ |
52 |
einstall |
53 |
cd ${D}/${CONF_LIBDIR} |
54 |
dodir /usr/${CONF_LIBDIR} |
55 |
mv blah blahdiddly moo ${D}/usr/${CONF_LIBDIR} |
56 |
more stuff here |
57 |
} |
58 |
|
59 |
|
60 |
...though, suggestions for a better way to do this would be appreciated. |
61 |
especially for solving problem #3. i'm going to have to edit econf so |
62 |
that it sees --prefix, sets a variable based on it, and then sets |
63 |
--libdir=/${myprefix}/${CONF_LIBDIR}. that -looks- like the easiest way |
64 |
to handle it to me, with myprefix=usr when --prefix isnt passed. |
65 |
|
66 |
|
67 |
Travis Tilley <lv@g.o> |
68 |
|
69 |
-- |
70 |
gentoo-dev@g.o mailing list |