On Wed 02 Apr 2014 17:14:02 Ben de Groot wrote: > On 1 April 2014 21:58, Alexandre Rostovtsev <[email protected]> wrote: > > On Tue, 2014-04-01 at 13:13 +0800, Ben de Groot wrote: > >> On 1 April 2014 06:16, Michał Górny <[email protected]> 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
signature.asc
Description: This is a digitally signed message part.
