[gentoo-dev] mulltiib cruft: /emul

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iQIVAwUARNoEOkFjO5/oN/WBAQICFQ/+KMzH/kXVsoHHA7KTWbQ2C10ikSM2805C
+DvDZ5t+XBFnpTgV5Adw02aNF2y+Xopht2wiHtGWw48zG5P+p+ dXRa405xMKqEN5
Z5CLgzld5fX32qHnsq5H8ddpLkpR7ioNyCsV9MX+eA9bYevoR3 HX4VvswTqauM54
ZXz4YtCG6nwJhmW9dHzWbePTB51XzQL3v+8AnNK2p7op3jaceg J4ku8yppW2diU9
xwRzROiUnbCDs50lunfqdCPMupQHM1wfNV3mya4RZRO6dfDx4t eQK21NC1QTZIjY
8LH878j0mK+XfAydX2oCOiCPugnhKu9YglcCtYAfZaJOmddjKQ 5qHqZjtJvO7Roa
G85OqltP78f9X6nTPYwlohJIPJkC0VI2pf1444d1ZcakLRF4a7 i7xfNI6r9cnUxD
P98BLkfF99bGFMyVCAaNVC+oj7kFhQOzwf6XVx3hv+MXorQ4Va +Iqz+3KdP+c0ed
/ExkDMmvXjQ6eUyu9XiURMZBzlVo1ZTAFU5r50CFfD3kPUVnUYa eUqi+FUg6tYrc
eYb1TxGpiNG6wVcryxJ6u38xF1Nh8dTKnxLnTKYnoP6GUZ7X0n 0ni4kg1FnKAIvl
JADvxXtFPav7eAP87zjiMdkKu53DhchBCSX4jzq/XbaTUtAUxmaMANjfTwHKEJqr
LsCk7eR02ys=
=nkPE
-----END PGP SIGNATURE-----

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

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

Duncan wrote:

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

*shrug* It's already been that way when I joined. I think at one point the
argument was exactly what you said.. to avoid collisions between the hacky
emul-stuff and real multilib-packages.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list

On Wed, 2006-09-08 at 19:47 +0200, Simon Stelling wrote:

> Duncan wrote:

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

>
> *shrug* It's already been that way when I joined. I think at one point the
> argument was exactly what you said.. to avoid collisions between the hacky
> emul-stuff and real multilib-packages.

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.

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


--
gentoo-dev@gentoo.org mailing list

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE22oTXVaO67S1rtsRAv0IAKCKQFNu0Upzq4vwdcIPJ1 +M5gWBHACgsPQi
KAMN68bcjyvZlEU4OPfFmoU=
=jy0i
-----END PGP SIGNATURE-----

-----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+KmCnEVjj8yeoscAXLZ ybg9oInK1+0eQy
VDAVU7q0gVf+WxCpiiQ8t+uhPL0tV6EGnJAkCx09dDNM6C+aOJ rW8a7KEiR9S6g5
SJWN4szCtaYNiPWzpvTvGwdHQ94jPvDDPq3tX4GQN22fF1fG2X xz56cBmvx+pXIU
40RLYip7wNs=
=Xpt4
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list