On Friday 20 August 2004 01:03, Travis Tilley wrote:
> supporting configurations where lib64 or lib32 is a directory will
> probably require a change in policy and a change in the dev quiz
> regarding the use of hardcoded lib directories in ebuilds and when
> einstall should be used.
>
> problem #1) with hardcoded references to lib, i have to go and fix each
> ebuild that does this by hand so that it will work with lib64 or lib32.
> there are a LOT more ebuilds that do this in the tree than i expected.
>
> problem #2) after having fixed ncurses so that it's libdir agnostic and
> can install into lib64, it was updated to have utf-8 support and that
> update included some more hardcoded references to lib. this broke
> ncurses for users with lib64, and there was one bug report where a user
> was unable to run anything linked against ncurses. so if an ebuild is
> CONF_LIBDIR aware, -all- references should use this variable (or another
> one set based on whether or not CONF_LIBDIR is set).
>
> problem #3) since econf might set libdir now, it's no longer sane to not
> set libdir during make install, either by setting it in the ebuild or by
> using einstall. ebuilds that use econf will have
> --libdir=/usr/${CONF_LIBDIR} when [ -z "${CONF_LIBDIR}" ] (this change
> is in the ebuild.sh in >= portage 2.0.51_pre18), so make install will
> try to install the libraries to the live filesystem if einstall isnt
> also used.
>
> problem #4) since the stable portage doesnt support CONF_LIBDIR and this
> variable will not be in all profiles even when it is supported, ebuilds
> that use this variable must default to setting it to lib. note that not
> all ebuilds will need to even touch this... anything that uses econf and
> einstall without using hardcoded lib references in the ebuild is already
> perfect.

Could you write an eclass that will do this automatically? (and change the 
ebuild documentation to include the CONF_LIBDIR variable and docs)

> none of these problems exist when using econf and einstall, and when
> you're not messing with libs in the ebuild. all the problems can also be
> avoided in ebuilds that mess with libs by simply using a variable. if
> there are any instances where einstall cant be used, that needs to be
> fixed in einstall so that it can be.
>
> so... maybe something like this for an ebuild that needs to install to
> /lib:
>
> pkg_setup() {
>     [ -z "${CONF_LIBDIR}" ] && export CONF_LIBDIR="lib"
> }
I believe should be in the global level or in src_compile, but I could be 
mistaken.

>
> src_compile(){
>     econf --libdir=/${CONF_LIBDIR} blah
>     emake
> }
>
> src_install(){
>     einstall
>     cd ${D}/${CONF_LIBDIR}
>     dodir /usr/${CONF_LIBDIR}
>     mv blah blahdiddly moo ${D}/usr/${CONF_LIBDIR}
>     more stuff here
> }
>
>
> ...though, suggestions for a better way to do this would be appreciated.
> especially for solving problem #3. i'm going to have to edit econf so
> that it sees --prefix, sets a variable based on it, and then sets
> --libdir=/${myprefix}/${CONF_LIBDIR}. that -looks- like the easiest way
> to handle it to me, with myprefix=usr when --prefix isnt passed.

Looks great.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net