[gentoo-dev] hardcoding lib in ebuilds, and using econf without einstall

[gentoo-dev] hardcoding lib in ebuilds, and using econf without einstall

[Travis Tilley]

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.


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"
}

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.


Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] hardcoding lib in ebuilds, and using econf without einstall

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

On Thursday 19 August 2004 07:03 pm, Travis Tilley wrote:
> 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.

there are a lot of ebuilds out there that dont use econf when they easily 
could ... so i guess people should be more diligent about seeing if `econf` 
works for them ...
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 838 bytes --]

Re: [gentoo-dev] hardcoding lib in ebuilds, and using econf without einstall

[Michael Sterrett -Mr. Bones.-]

On Thu, 19 Aug 2004, Travis Tilley wrote:

> 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.

No, einstall is not the preferred method.

    make DESTDIR="${D}" install || die "make install failed"

is the preferred method.  That should work fine for Makefiles that aren't
broken with regard to DESTDIR.  If the Makefiles *are* broken, the best
thing to do is to fix them and submit a patch upstream.  If that's not
done, *then* falling back to einstall is fine, but that shouldn't be the
first choice.

Michael Sterrett
  -Mr. Bones.-
mr_bones_@gentoo.org

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] hardcoding lib in ebuilds, and using econf without einstall

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

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.

Probably because it is in the skel.ebuild file, first fix that ;-)

Paul

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

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] hardcoding lib in ebuilds, and using econf without einstall

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 3348 bytes --]

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

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] hardcoding lib in ebuilds, and using econf without einstall

[Blackace]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

On Fri, 2004-08-20 at 01:11, Paul de Vrieze wrote:
> I believe should be in the global level or in src_compile, but I could be 
> mistaken.

I don't believe anything like that should be done in the global level.

Ever.

-- 
Blackace
Gentoo Linux
Infrastructure Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]