[gentoo-dev] Two requests for ebuild maintainers+writers

[gentoo-dev] Two requests for ebuild maintainers+writers

[Travis Tilley]

I have two requests that will help to make my work incredibly easy. ;)

1) start using $(get_libdir) wherever possible instead of referencing 
lib directly. get_libdir is now part of the eutils eclass and is used by 
gen_usr_ldscript in eutils. so, where previously it had:

cat > ${D}/usr/lib/$1 <<"END_LDSCRIPT"

it now has:

cat > ${D}/usr/$(get_libdir)/$1 <<"END_LDSCRIPT"

The get_libdir function will always return "lib" if using portage 
<2.0.51_pre20 or if CONF_LIBDIR isnt set, so it should be safe to use 
-everywhere-. If CONF_LIBDIR is set, it should return lib32 or lib64, 
depending on what multilib capable arch you are running on. package 
maintainers arent expected to be aware of any issues with using 
lib32/lib64 (well, unless you're an amd64 dev or helping with multilib 
on mips i guess), so feel free to slap any bugs related to lib64/lib32 
onto the arch maintainers. ;)

please mark any lib32/lib64 bugs critical so that they're sure to be 
noticed, even if they're not technically critical. *pokes amd64 devs so 
that they know this was requested and dont downgrade any of those bugs*


2) install and use gcc 3.4 if possible. this isnt a biggie for most 
archs, i'd just like for packages to be tested with gcc 3.4 since I 
havent run into any major problems on amd64 in a while, and would like 
to know what x86 or ppc specifics fail (i expect there to be a small few 
that only fail on these archs). Note that i'm not requesting anyone 
-switch- to gcc 3.4 here, just that they test the packages they maintain 
to see if they fail, and fix them if possible.

a note about c++ apps: if you dont plan on switching to gcc 3.4 
completely, it might not be easy to test any c++ apps. 3.4 includes an 
incompatible libstdc++, and strange bugs pop up or apps fail to compile 
when one dep links to .so.5 (gcc 3.2.3->3.3.x) and another links to 
.so.6 (gcc 3.4.x). they dont -always- pop up, but they -often- do. if 
you keep gcc 3.3 around, some retarded apps still link to .so.5 even 
when compiled using 3.4 unless you move gcc 3.3's libstdc++.so out of 
the way. :/
gcc 3.4 is slotted, but if you switch completely, the suggestion is to 
remove 3.3.x and 3.2.x.

morfic has also been kind enough to provide us with an experimental gcc 
3.4 on x86 profile for those willing to make the switch: 
profiles/default-linux/x86/2004.2/gcc34/


Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Two requests for ebuild maintainers+writers

[Paul de Vrieze]

On Wednesday 25 August 2004 21:43, Travis Tilley wrote:
> I have two requests that will help to make my work incredibly easy. ;)
>
> 1) start using $(get_libdir) wherever possible instead of referencing
> lib directly. get_libdir is now part of the eutils eclass and is used by
> gen_usr_ldscript in eutils. so, where previously it had:

One question abou this. Currently java archives are instaled in /usr/lib. They 
are obviously architecture independent. Should we still use $(get_libdir) for 
those, or is there maybe an independent dir.

Paul

ps. As a sidenote, wouldn't it be better to also make the /usr part dynamic? 
That makes package relocation fairly easy.

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

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Two requests for ebuild maintainers+writers

[Travis Tilley]

Paul de Vrieze wrote:
> On Wednesday 25 August 2004 21:43, Travis Tilley wrote:
> 
>>I have two requests that will help to make my work incredibly easy. ;)
>>
>>1) start using $(get_libdir) wherever possible instead of referencing
>>lib directly. get_libdir is now part of the eutils eclass and is used by
>>gen_usr_ldscript in eutils. so, where previously it had:
> 
> 
> One question abou this. Currently java archives are instaled in /usr/lib. They 
> are obviously architecture independent. Should we still use $(get_libdir) for 
> those, or is there maybe an independent dir.
> 
> Paul
> 
> ps. As a sidenote, wouldn't it be better to also make the /usr part dynamic? 
> That makes package relocation fairly easy.


java is going to be stress if we have to support both a 64bit and 32bit 
jre... especially since azureus needs a 64bit SWT to work and such. i'd 
say that java stuff should probably not use $(get_libdir), or (almost) 
anything that ends up in /opt. that is, indeed, a good question that i 
hadnt thought of.

the chunk of the FHS that mentions lib64 notes that 64bit libraries 
should go there... so if it isnt a library and lives in lib, you might 
also not want to use $(get_libdir)... but that would all depend on how 
jstubbs eventually implements multilib dependency handling in portage, 
so it might just be safer to use $(get_libdir) even then to prevent file 
collisions. at the very least, it shouldnt cause problems on 
non-multilib systems since "$(get_libdir)" will always equal "lib" on 
them, and you dont have to worry about collisions. ;p

*pokes jstubbs*


Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Two requests for ebuild maintainers+writers

[Paul de Vrieze]

On Friday 27 August 2004 18:51, Travis Tilley wrote:
> java is going to be stress if we have to support both a 64bit and 32bit
> jre... especially since azureus needs a 64bit SWT to work and such. i'd
> say that java stuff should probably not use $(get_libdir), or (almost)
> anything that ends up in /opt. that is, indeed, a good question that i
> hadnt thought of.

Actually the jar archives still should run on both systems. However the 
architecture dependend (native) libs need to be located in their respective 
dirs. That should magically work with either jdk (if both native libs are 
installed) as long as the jar archives can be found. They should be the same 
so also located at the same location.

>
> the chunk of the FHS that mentions lib64 notes that 64bit libraries
> should go there... so if it isnt a library and lives in lib, you might
> also not want to use $(get_libdir)... but that would all depend on how
> jstubbs eventually implements multilib dependency handling in portage,
> so it might just be safer to use $(get_libdir) even then to prevent file
> collisions. at the very least, it shouldnt cause problems on
> non-multilib systems since "$(get_libdir)" will always equal "lib" on
> them, and you dont have to worry about collisions. ;p

I guess the trick is to see where the installation scripts for the package 
install it.

Paul

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

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Two requests for ebuild maintainers+writers

[Andrej Kacian]

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

On Wed, 25 Aug 2004 15:43:48 -0400
Travis Tilley <lv@gentoo.org> wrote:

> 1) start using $(get_libdir) wherever possible instead of referencing 
> lib directly. get_libdir is now part of the eutils eclass and is used by 
> gen_usr_ldscript in eutils. so, where previously it had:

Does this apply for python packages that install files in /usr/lib/python/... ?

-- 
/~\ The ASCII        Andrej "Ticho" Kacian <ticho at gentoo dot org>
\ / Ribbon Campaign  GnuPG public key ID: 7CD93FE2 (pgp.mit.edu)
 X  Against HTML     Key fingerprint:
/ \ Email!           E87D 9DEF 2A23 6FFB 7AD9 542F 4253 3A46 7CD9 3FE2

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

Re: [gentoo-dev] Two requests for ebuild maintainers+writers

[Travis Tilley]

Andrej Kacian wrote:
> On Wed, 25 Aug 2004 15:43:48 -0400
> Travis Tilley <lv@gentoo.org> wrote:
> 
> 
>>1) start using $(get_libdir) wherever possible instead of referencing 
>>lib directly. get_libdir is now part of the eutils eclass and is used by 
>>gen_usr_ldscript in eutils. so, where previously it had:
> 
> 
> Does this apply for python packages that install files in /usr/lib/python/... ?


I guess I should have clarified a bit. It applies to any non-binary-only 
non-bytecode non-script library. $(get_libdir) is there to make sure 
that 64bit libraries go into lib64 on amd64, and 32bit ones go into lib. 
or that N64 objects on mips go into lib64, N32 in lib32, and O32 in lib 
(at least i -think- that's how they eventually want it set up?).

The way python is currently patched, it -should- be looking in lib64 as 
well as lib, and using $(get_libdir) shouldnt change the behavior on 
non-multilib archs at all, so it wouldnt have hurt to use it... but i 
guess this is one case where it would make more sense to not use 
$(get_libdir). sorry about that ^^;


Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list