[gentoo-dev] mulltiib cruft: /emul

[gentoo-dev] mulltiib cruft: /emul

[Mike Frysinger]

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

looks like your mail server ate this ...

someone remind me why our emul packages install in some obscure directory tree 
rooted in /emul

if we moved these things to the standard lib32 dirs, it would certainly ease 
the pain of people doing multilib building, both in and out of portage

it'd also let us free up env.d crap ... but most importantly, it'll stop 
breaking my friggin tab completion for /etc
-mike

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

[gentoo-dev] Re: mulltiib cruft: /emul

[Duncan]

Mike Frysinger <vapier@gentoo.org> posted
200608081143.13375.vapier@gentoo.org, excerpted below, on  Tue, 08 Aug
2006 11:43:13 -0400:

> looks like your mail server ate this ...
> 
> someone remind me why our emul packages install in some obscure
> directory tree rooted in /emul
> 
> if we moved these things to the standard lib32 dirs, it would certainly
> ease the pain of people doing multilib building, both in and out of
> portage
> 
> it'd also let us free up env.d crap ... but most importantly, it'll stop
> breaking my friggin tab completion for /etc

It came thru b4.  As an amd64 user, I've been hoping a member of the arch
team would reply, as it's a question that seeing it asked, I'm now curious
about myself, but nothing yet.

Pure speculation here, but the idea /might/ have been to separate prebuilt
binary stuff into /emul, so it wouldn't conflict with future multiarch
portage support (which would presumably use /lib32), which IIRC was hoped
to be here by now, but turned out to be rather complicated and had no
portage devs which had that particular itch they needed to scratch, so... 
(IOW, no blame or finger pointing, just that we'd hoped it'd be here by
2.1, and it isn't, and that's a fact amd64 continues to have to deal with.)

As I said, pure speculation, likely wrong, but that's the first logical
thing that came to my mind.  I too am interested in a real answer.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: mulltiib cruft: /emul

[Mike Frysinger]

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

On Wednesday 09 August 2006 10:57, Duncan wrote:
> Mike Frysinger <vapier@gentoo.org> posted
> > looks like your mail server ate this ...
> >
> > someone remind me why our emul packages install in some obscure
> > directory tree rooted in /emul
> >
> > if we moved these things to the standard lib32 dirs, it would certainly
> > ease the pain of people doing multilib building, both in and out of
> > portage
> >
> > it'd also let us free up env.d crap ... but most importantly, it'll stop
> > breaking my friggin tab completion for /etc
>
> It came thru b4.  As an amd64 user, I've been hoping a member of the arch
> team would reply, as it's a question that seeing it asked, I'm now curious
> about myself, but nothing yet.

i asked some others and they didnt get the e-mail either ... looks like our 
gentoo mail server is really starting to crash here ...

> Pure speculation here, but the idea /might/ have been to separate prebuilt
> binary stuff into /emul, so it wouldn't conflict with future multiarch
> portage support (which would presumably use /lib32), which IIRC was hoped
> to be here by now, but turned out to be rather complicated and had no
> portage devs which had that particular itch they needed to scratch, so...
> (IOW, no blame or finger pointing, just that we'd hoped it'd be here by
> 2.1, and it isn't, and that's a fact amd64 continues to have to deal with.)

from what i remember, /emul was done because that's how some other distro was 
doing it ... but at the time i was staying out of multilib development 
because it sucked and i didnt have an amd64

now i have an amd64 and this current state annoys me greatly, so rather than 
bitch all the time, i want to fix it
-mike

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

Re: [gentoo-dev] Re: mulltiib cruft: /emul

[Danny van Dyk]

Am Mittwoch, 9. August 2006 17:50 schrieb Mike Frysinger:
> On Wednesday 09 August 2006 10:57, Duncan wrote:
> > Mike Frysinger <vapier@gentoo.org> posted
> > Pure speculation here, but the idea /might/ have been to separate
> > prebuilt binary stuff into /emul, so it wouldn't conflict with
> > future multiarch portage support (which would presumably use
> > /lib32), which IIRC was hoped to be here by now, but turned out to
> > be rather complicated and had no portage devs which had that
> > particular itch they needed to scratch, so... (IOW, no blame or
> > finger pointing, just that we'd hoped it'd be here by 2.1, and it
> > isn't, and that's a fact amd64 continues to have to deal with.)
>
> from what i remember, /emul was done because that's how some other
> distro was doing it ... but at the time i was staying out of multilib
> development because it sucked and i didnt have an amd64
>
> now i have an amd64 and this current state annoys me greatly, so
> rather than bitch all the time, i want to fix it

Herbs is maintaing the emul-libraries.
IMHO it shouldn't be to hard to change it from /emul to /lib32 
and /usr/lib32. And yes, /emul was there from the very beginning aka 
Tester/brad_mssw :-)

Danny
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: mulltiib cruft: /emul

[Richard Fish]

On 8/9/06, Mike Frysinger <vapier@gentoo.org> wrote:
> i asked some others and they didnt get the e-mail either ... looks like our
> gentoo mail server is really starting to crash here ...

http://bugs.gentoo.org/show_bug.cgi?id=141904

-Richard
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: mulltiib cruft: /emul

[Donnie Berkholz]

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

Olivier Crete wrote:
> It was chosen by brad_mssw to match the way it is done on ia64. And I
> think we should continue to put the binary
> app-emulation/emul-linux-x86-* in /emul/  and that lib32 should be
> reserved for properly installed packages using portage whenever we
> manage to get portage to support it.

It makes sense that you wouldn't want these binary packages going into
/lib32 or /usr/lib32, but /emul seems like an odd choice compared to
something like /opt/lib32.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Re: mulltiib cruft: /emul

[Mike Doty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Donnie Berkholz wrote:
> Olivier Crete wrote:
>> It was chosen by brad_mssw to match the way it is done on ia64. And I
>> think we should continue to put the binary
>> app-emulation/emul-linux-x86-* in /emul/  and that lib32 should be
>> reserved for properly installed packages using portage whenever we
>> manage to get portage to support it.
> 
> It makes sense that you wouldn't want these binary packages going into
> /lib32 or /usr/lib32, but /emul seems like an odd choice compared to
> something like /opt/lib32.
> 
> Thanks,
> Donnie
> 
IIRC, /emul predates FHS acceptance.  also, while they are "binary"
packages, they arn't in the same catagory as binary-only packages.  We
distribute them to assist multilib and to overcome problems that portage
wasn't really designed for.

We're getting to the point where most emul stuff could be made obsolete.
 The amd64 team is having a meeting next week and I'll bring the point up.

- --
=======================================================
Mike Doty                      kingtaco -at- gentoo.org
Gentoo/AMD64 Strategic Lead
Gentoo Developer Relations
Gentoo Recruitment Lead
Gentoo Infrastructure
GPG: E1A5 1C9C 93FE F430 C1D6  F2AF 806B A2E4 19F4 AE05
=======================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iQCVAwUBRNtsMIBrouQZ9K4FAQKtnAP+KmCnEVjj8yeoscAXLZybg9oInK1+0eQy
VDAVU7q0gVf+WxCpiiQ8t+uhPL0tV6EGnJAkCx09dDNM6C+aOJrW8a7KEiR9S6g5
SJWN4szCtaYNiPWzpvTvGwdHQ94jPvDDPq3tX4GQN22fF1fG2Xxz56cBmvx+pXIU
40RLYip7wNs=
=Xpt4
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: mulltiib cruft: /emul

[Kevin F. Quinn]

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

On Thu, 10 Aug 2006 12:26:10 -0500
Mike Doty <kingtaco@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Donnie Berkholz wrote:
> > Olivier Crete wrote:
> >> It was chosen by brad_mssw to match the way it is done on ia64.
> >> And I think we should continue to put the binary
> >> app-emulation/emul-linux-x86-* in /emul/  and that lib32 should be
> >> reserved for properly installed packages using portage whenever we
> >> manage to get portage to support it.
> > 
> > It makes sense that you wouldn't want these binary packages going
> > into /lib32 or /usr/lib32, but /emul seems like an odd choice
> > compared to something like /opt/lib32.

I though exactly this when I saw SpanKY's query.  Having a directory in
'/' is not pretty.

> IIRC, /emul predates FHS acceptance.  also, while they are "binary"
> packages, they arn't in the same catagory as binary-only packages.  We
> distribute them to assist multilib and to overcome problems that
> portage wasn't really designed for.

More generally we have varying approaches to pre-built packages;
app-office/openoffice-bin installs to /usr for example, while
mail-client/mozilla-thunderbird-bin and www-client/mozilla-firefox-bin
install to /opt.

In these cases, where they are installed on the same target
architecture as they were built, I think it makes sense to have them
install as if they were built with 'emerge -B' for installation via
'emerge -K' - i.e. in /usr rather than /opt.

x86-built binary packages for x86_64 are not the same, of course.  One
idea that springs to mind immediately is to put them in a
{bin,include,lib...} hierarchy under /usr/<ctarget> (which is also
where the compiler stuff for <ctarget> ends up).  Conceptually at least
(although no doubt problematic in practice) on x86_64 one could use a
x86(_32) cross-compiler to build stuff to ROOT=/usr/${CTARGET}.  Again
in concept a /${CTARGET}/{bin,include,lib...} would exists for
essential boot stuff, althought that's a bit academic.

Just a thought for the pot ;)

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] Re: mulltiib cruft: /emul

[Mike Frysinger]

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

On Thursday 10 August 2006 15:42, Kevin F. Quinn wrote:
> On Thu, 10 Aug 2006 12:26:10 -0500
>
> Mike Doty <kingtaco@gentoo.org> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Donnie Berkholz wrote:
> > > Olivier Crete wrote:
> > > It makes sense that you wouldn't want these binary packages going
> > > into /lib32 or /usr/lib32, but /emul seems like an odd choice
> > > compared to something like /opt/lib32.
>
> I though exactly this when I saw SpanKY's query.  Having a directory in
> '/' is not pretty.

it doesnt matter whether it's in /emul or /opt or /fooie, if it isnt in the 
system lib32 paths, it's going to be a pita

using the system lib32 paths allows the compiler/linker/loader to 
automatically locate the libraries

> More generally we have varying approaches to pre-built packages;
> app-office/openoffice-bin installs to /usr for example, while
> mail-client/mozilla-thunderbird-bin and www-client/mozilla-firefox-bin
> install to /opt.

which is broken ... OOo-bin should be in /opt ...
-mike

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

Re: [gentoo-dev] Re: mulltiib cruft: /emul

[Donnie Berkholz]

Mike Frysinger wrote:
> On Thursday 10 August 2006 15:42, Kevin F. Quinn wrote:
>> More generally we have varying approaches to pre-built packages;
>> app-office/openoffice-bin installs to /usr for example, while
>> mail-client/mozilla-thunderbird-bin and www-client/mozilla-firefox-bin
>> install to /opt.
> 
> which is broken ... OOo-bin should be in /opt ...

There's a reason for that, it breaks switching between the two because 
the .openoffice dir or something has the path in it.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: mulltiib cruft: /emul

[Chris Gianelloni]

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

On Thu, 2006-08-10 at 12:26 -0500, Mike Doty wrote:
> We're getting to the point where most emul stuff could be made obsolete.
>  The amd64 team is having a meeting next week and I'll bring the point up.

Just don't screw over games in the process.  ;]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: mulltiib cruft: /emul

[Doug Goldstein]

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

Mike Frysinger wrote:
> On Thursday 10 August 2006 12:48, Olivier Crete wrote:
>> And I think we should continue to put the binary
>> app-emulation/emul-linux-x86-* in /emul/  and that lib32 should be
>> reserved for properly installed packages using portage whenever we
>> manage to get portage to support it.
> 
> either you use the prebuilt binaries or you dont
> 
> keeping these things in /emul just bloats the default amd64 system and makes 
> typical use a pita (adding -L/emul/... is wicked lame)
> -mike

Did you just want to use wicked in a sentence? I bet you did.

Also, I can probably hit brad_mssw for you if you want. Since I work
with him now.

-- 
Doug Goldstein <cardoe@gentoo.org>
http://dev.gentoo.org/~cardoe/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Re: mulltiib cruft: /emul

[Mike Frysinger]

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

On Thursday 10 August 2006 19:32, Doug Goldstein wrote:
> Also, I can probably hit brad_mssw for you if you want. Since I work
> with him now.

hindsight is 20/20 eh ?  no point in "blaming" people for decisions made when 
at the time, said decisions were the "best"
-mike

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

Re: [gentoo-dev] mulltiib cruft: /emul

[Herbie Hopkins]

On Tue, Aug 08, 2006 at 11:43:13AM -0400, Mike Frysinger wrote:
> someone remind me why our emul packages install in some obscure directory tree 
> rooted in /emul
> 
> if we moved these things to the standard lib32 dirs, it would certainly ease 
> the pain of people doing multilib building, both in and out of portage


Mike, Sorry I missed you on irc yesterday, didn't get back til later than
expected.

I'm not sure why /emul was originally chosen though it's a choice I've
just gone along with whilst maintaining these packages. I've always
viewed the emul libs as a temporary measure until we had full multilib
fuctionality in portage. Afaik the only person working on this was
eradicator who has been mia for a while now so I'm unsure weather this
is ever likely to arise. Given that it looks like we'll be stuck with
these binary libs for some time yet then we may as well do as you
suggest and install them in a standard location to make building against
them a bit easier. I'll look into doing this when I next version bump the
packages.

Herbs


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] mulltiib cruft: /emul

[Olivier Crête]

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

On Mon, 2006-21-08 at 12:21 +0100, Herbie Hopkins wrote:
> On Tue, Aug 08, 2006 at 11:43:13AM -0400, Mike Frysinger wrote:
> > someone remind me why our emul packages install in some obscure directory tree 
> > rooted in /emul
> > 
> > if we moved these things to the standard lib32 dirs, it would certainly ease 
> > the pain of people doing multilib building, both in and out of portage
> 
> 
> Mike, Sorry I missed you on irc yesterday, didn't get back til later than
> expected.
> 
> I'm not sure why /emul was originally chosen though it's a choice I've
> just gone along with whilst maintaining these packages.

It was chosen because emul packages are put in /emul on ia64.

> I've always viewed the emul libs as a temporary measure until we had full multilib
> fuctionality in portage. Afaik the only person working on this was
> eradicator who has been mia for a while now so I'm unsure weather this
> is ever likely to arise. Given that it looks like we'll be stuck with
> these binary libs for some time yet then we may as well do as you
> suggest and install them in a standard location to make building against
> them a bit easier. I'll look into doing this when I next version bump the
> packages.

I still believe we should reserve the regular directory for the real
multilib stuff, otherwise it will be very painful when we decide to
move. And continue to put the stopgap binary packages in /emul.

-- 
Olivier Crête
tester@gentoo.org

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

Re: [gentoo-dev] mulltiib cruft: /emul

[Mike Frysinger]

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

On Monday 21 August 2006 10:29, Olivier Crête wrote:
> On Mon, 2006-21-08 at 12:21 +0100, Herbie Hopkins wrote:
> > I've always viewed the emul libs as a temporary measure until we had full
> > multilib fuctionality in portage. Afaik the only person working on this
> > was eradicator who has been mia for a while now so I'm unsure weather
> > this is ever likely to arise. Given that it looks like we'll be stuck
> > with these binary libs for some time yet then we may as well do as you
> > suggest and install them in a standard location to make building against
> > them a bit easier. I'll look into doing this when I next version bump the
> > packages.
>
> I still believe we should reserve the regular directory for the real
> multilib stuff, otherwise it will be very painful when we decide to
> move. And continue to put the stopgap binary packages in /emul.

why ?  this is what blockers are for
-mike

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

Re: [gentoo-dev] mulltiib cruft: /emul

[Olivier Crete]

On Mon, 2006-21-08 at 13:28 -0400, Mike Frysinger wrote:
> On Monday 21 August 2006 10:29, Olivier Crête wrote:
> > On Mon, 2006-21-08 at 12:21 +0100, Herbie Hopkins wrote:
> > > I've always viewed the emul libs as a temporary measure until we had full
> > > multilib fuctionality in portage. Afaik the only person working on this
> > > was eradicator who has been mia for a while now so I'm unsure weather
> > > this is ever likely to arise. Given that it looks like we'll be stuck
> > > with these binary libs for some time yet then we may as well do as you
> > > suggest and install them in a standard location to make building against
> > > them a bit easier. I'll look into doing this when I next version bump the
> > > packages.
> >
> > I still believe we should reserve the regular directory for the real
> > multilib stuff, otherwise it will be very painful when we decide to
> > move. And continue to put the stopgap binary packages in /emul.
> 
> why ?  this is what blockers are for

Will we make emul-x86-gtk-libs block gtk+? We dont have use based
deps/blockers... how long will it take before we have API/arch based
ones. In my humble opinion, keeping that stuff in emul is much better,
in the same way as we would install binary packages in /opt and
not /usr.

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] mulltiib cruft: /emul

[Mike Frysinger]

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

On Monday 21 August 2006 13:39, Olivier Crete wrote:
> Will we make emul-x86-gtk-libs block gtk+? We dont have use based
> deps/blockers...

building for ABI is unrelated to USE flags

> how long will it take before we have API/arch based 
> ones.

you really think having users build ABI stuff on the fly is due to come out 
soon ?

> In my humble opinion, keeping that stuff in emul is much better, 
> in the same way as we would install binary packages in /opt and
> not /usr.

then you have mixed packages installed ... when you build a 32bit app against 
GTK+, which version is going to be used at link time ?  /emul ?  /lib32 ?  
how about at run time ?
-mike

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

Re: [gentoo-dev] mulltiib cruft: /emul

[Donnie Berkholz]

Herbie Hopkins wrote:
> I'm not sure why /emul was originally chosen though it's a choice I've
> just gone along with whilst maintaining these packages. I've always
> viewed the emul libs as a temporary measure until we had full multilib
> fuctionality in portage. Afaik the only person working on this was
> eradicator who has been mia for a while now so I'm unsure weather this
> is ever likely to arise. 

blubb was working on this but ran out of time for it or something, he 
wrote a proto-GLEP that I've got lying around.  I'm thinking of seeing 
what I can do because the current situation really annoys me, even 
though I don't have a multilib box.

> Given that it looks like we'll be stuck with
> these binary libs for some time yet then we may as well do as you
> suggest and install them in a standard location to make building against
> them a bit easier. I'll look into doing this when I next version bump the
> packages.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: mulltiib cruft: /emul

[Duncan]

Donnie Berkholz <dberkholz@gentoo.org> posted 44EA17DE.6050503@gentoo.org,
excerpted below, on  Mon, 21 Aug 2006 13:30:22 -0700:

> Herbie Hopkins wrote:
>> I'm not sure why /emul was originally chosen though it's a choice I've
>> just gone along with whilst maintaining these packages. I've always
>> viewed the emul libs as a temporary measure until we had full multilib
>> fuctionality in portage. Afaik the only person working on this was
>> eradicator who has been mia for a while now so I'm unsure weather this
>> is ever likely to arise. 
> 
> blubb was working on this but ran out of time for it or something, he 
> wrote a proto-GLEP that I've got lying around.  I'm thinking of seeing 
> what I can do because the current situation really annoys me, even 
> though I don't have a multilib box.

FWIW, eradicator active once again.
eselect-compiler: http://bugs.gentoo.org/show_bug.cgi?id=143697

BTW @ jakob and antarus re comment #18, 21: While I understand and don't
disagree with toolchain's eselect-compiler masking, for some of us on
amd64 and already used to dealing with its quirks, eselect-compiler is
less the "broken thing" than gcc-config-1* was.  After all, there'd have
never been a need for eselect-compiler if gcc-config wasn't broken re dual
bitness in the first place.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: mulltiib cruft: /emul

[Mike Frysinger]

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

On Tuesday 22 August 2006 11:17, Duncan wrote:
> FWIW, eradicator active once again

sorry, but not really

active when it comes to something core like toolchain does not describe 
eradicator's behavior

> After all, there'd have
> never been a need for eselect-compiler if gcc-config wasn't broken re dual
> bitness in the first place.

has nothing to do with being broken, each has a different design

multilib support in Gentoo in general is screwed up as a result of the slow 
grafting process it has gone through ... there has yet to be a real design 
plan for it
-mike

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

Re: [gentoo-dev] mulltiib cruft: /emul

[Chris Gianelloni]

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

On Mon, 2006-08-21 at 12:21 +0100, Herbie Hopkins wrote:
> On Tue, Aug 08, 2006 at 11:43:13AM -0400, Mike Frysinger wrote:
> > someone remind me why our emul packages install in some obscure directory tree 
> > rooted in /emul
> > 
> > if we moved these things to the standard lib32 dirs, it would certainly ease 
> > the pain of people doing multilib building, both in and out of portage
> 
> 
> Mike, Sorry I missed you on irc yesterday, didn't get back til later than
> expected.
> 
> I'm not sure why /emul was originally chosen though it's a choice I've
> just gone along with whilst maintaining these packages. I've always
> viewed the emul libs as a temporary measure until we had full multilib
> fuctionality in portage. Afaik the only person working on this was
> eradicator who has been mia for a while now so I'm unsure weather this
> is ever likely to arise. Given that it looks like we'll be stuck with
> these binary libs for some time yet then we may as well do as you
> suggest and install them in a standard location to make building against
> them a bit easier. I'll look into doing this when I next version bump the
> packages.

Don't forget that this will require an update to (at least)
eselect-opengl, too.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] mulltiib cruft: /emul

[Herbie Hopkins]

On Thu, Aug 24, 2006 at 04:58:02PM -0400, Chris Gianelloni wrote:
> Don't forget that this will require an update to (at least)
> eselect-opengl, too.

Actually I'm not sure it would. eselect-opengl currently checks
/usr/lib[,64,32]/opengl/ for 32bit opengl libs libs and only finds the
emul libs since we create a symlink -> /emul. We just would't need the
symlink anymore since this is where they'd actually be installed.

Herbs


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] mulltiib cruft: /emul

[Chris Gianelloni]

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

On Fri, 2006-08-25 at 13:26 +0100, Herbie Hopkins wrote:
> On Thu, Aug 24, 2006 at 04:58:02PM -0400, Chris Gianelloni wrote:
> > Don't forget that this will require an update to (at least)
> > eselect-opengl, too.
> 
> Actually I'm not sure it would. eselect-opengl currently checks
> /usr/lib[,64,32]/opengl/ for 32bit opengl libs libs and only finds the
> emul libs since we create a symlink -> /emul. We just would't need the
> symlink anymore since this is where they'd actually be installed.

Cool.  That was either changed at some point, or my brain is still stuck
on opengl-update.  ;]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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