[gentoo-dev] mulltiib cruft: /emul

[gentoo-dev] mulltiib cruft: /emul

[Mike Frysinger]

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

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

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

[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 --]

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

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