Re: [gentoo-dev] Stable masks on multilib packages

[Mike Frysinger <vapier@gentoo.org>]

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

On Wed 02 Apr 2014 17:14:02 Ben de Groot wrote:
> On 1 April 2014 21:58, Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> > On Tue, 2014-04-01 at 13:13 +0800, Ben de Groot wrote:
> >> On 1 April 2014 06:16, Michał Górny <mgorny@gentoo.org> wrote:
> >> > Hello, all.
> >> > 
> >> > The late multilib ppc issues made me re-check our stable masks on
> >> > abi_x86_* flags and, honestly, I'm not sure if we're doing things
> >> > the right way.
> >> > 
> >> > That said, I have an alternate idea inspired by the ppc breakage.
> >> > 
> >> > Your thoughts?
> >> 
> >> In my opinion your multilib approach introduces an unnecessary degree
> >> of complexity, which --as has been shown here again-- is prone to
> >> breakage.
> >> 
> >> It would be best for our beloved distro to revert all the multilib
> >> changes, and try a different approach, or leave this prone-to-breakage
> >> implementation to an overlay for the few people who would actually
> >> benefit from it.
> > 
> > Speaking as a wine maintainer, the emul-linux-x86-* approach has many
> > times been proven to be an embarrassing failure and the main source of
> > pain and frustration for wine users. The sooner emul-linux-x86-* can be
> > removed from the tree, the better for Gentoo.
> 
> I would like to see an honest cost-benefit analysis of the
> emul-linux-x86 approach compared to the multilib eclass approach.
> Because in my experience the latter introduces more breakage and
> higher maintenance costs.

the emul-linux-* approach is a terrible idea.  it has obviously proven to:
 - not scale (sorry, but x86 is not the only ABI out there people care about)
 - be a huge pita to update/maintain
 - require shipping a lot of precompiled code

the multilib eclasses aren't perfect, but they're a hell of a lot better than 
the emul-linux-* approach.  we've been carrying that crap for over 10 years 
and it's gone literally nowhere.  considering it as a viable alternative to 
the multilib eclasses is preposterous at best.
-mike

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