On 1 April 2014 21:58, Alexandre Rostovtsev <tetrom...@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 <mgo...@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. > I am aware of only two solutions to the emul-linux-x86-* problems : > multilib-portage and multilib-build.eclass. The first requires everybody > to switch to a new package manager. The second allows us to keep using > portage, but requires library maintainers to add some simple boilerplate > to their ebuilds for multilib support. > > Do you have yet another alternative in mind? In my mind the emul-linux-x86 approach is more acceptable. I don't have experience with multilib-portage, as I don't have a use case for it. Another option, which seems to me to be more reasonable and which has greatly lower maintenance costs, is using a chroot. -- Cheers, Ben | yngwin Gentoo developer