Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: mulltiib cruft: /emul
Date: Tue, 22 Aug 2006 15:24:15
Message-Id: ecf76e$1hm$3@sea.gmane.org
In Reply to: Re: [gentoo-dev] mulltiib cruft: /emul by Donnie Berkholz
1 Donnie Berkholz <dberkholz@g.o> posted 44EA17DE.6050503@g.o,
2 excerpted below, on Mon, 21 Aug 2006 13:30:22 -0700:
3
4 > Herbie Hopkins wrote:
5 >> I'm not sure why /emul was originally chosen though it's a choice I've
6 >> just gone along with whilst maintaining these packages. I've always
7 >> viewed the emul libs as a temporary measure until we had full multilib
8 >> fuctionality in portage. Afaik the only person working on this was
9 >> eradicator who has been mia for a while now so I'm unsure weather this
10 >> is ever likely to arise.
11 >
12 > blubb was working on this but ran out of time for it or something, he
13 > wrote a proto-GLEP that I've got lying around. I'm thinking of seeing
14 > what I can do because the current situation really annoys me, even
15 > though I don't have a multilib box.
16
17 FWIW, eradicator active once again.
18 eselect-compiler: http://bugs.gentoo.org/show_bug.cgi?id=143697
19
20 BTW @ jakob and antarus re comment #18, 21: While I understand and don't
21 disagree with toolchain's eselect-compiler masking, for some of us on
22 amd64 and already used to dealing with its quirks, eselect-compiler is
23 less the "broken thing" than gcc-config-1* was. After all, there'd have
24 never been a need for eselect-compiler if gcc-config wasn't broken re dual
25 bitness in the first place.
26
27 --
28 Duncan - List replies preferred. No HTML msgs.
29 "Every nonfree program has a lord, a master --
30 and if you use the program, he is your master." Richard Stallman
31
32 --
33 gentoo-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-dev] Re: mulltiib cruft: /emul Mike Frysinger <vapier@g.o>