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