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

["Duncan" <1i5t5.duncan@cox.net>]

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