On Wed, 2014-04-02 at 17:14 +0800, Ben de Groot wrote: > 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.
libfoo-1.5 becomes available ~arch. Users install it. Users realize that libfoo-1.5's headers are incompatible with libfoo-1.4 binaries from emul-linux-x86-bar after they try to build wine and get a failure 30 minutes into the compile. So users complain about gentoo's wine support. libfoo-1.5 is stabilized. Of course, emul-linux-x86-bar has not been updated immediately, because *all* parts of emul-linux-x86 need to be updated at once due to a complex network of library interdependencies, and then manually checked for sanity, and the folks taking care of emul-linux-x86 can only really afford to do it 2, max 3 times per year. So more users install libfoo-1.5, and see wine fail, and complain more about gentoo's wine support until a new emul-linux-x86 release is rolled out a couple months later. But meanwhile, libbaz-5.0 becomes available in ~arch, and its headers are backwards-incompatible with libbaz-4.2 binaries in emul-linux-x86-wombatlibs... And this happens, oh, only every time there are API changes in libpng, jpeg, llvm, gnutls, libxml2, pulseaudio, etc.
signature.asc
Description: This is a digitally signed message part
