On 04/01/2014 10:43 PM, Rich Freeman wrote: > On Tue, Apr 1, 2014 at 9:58 AM, Alexandre Rostovtsev > <[email protected]> wrote: >> On Tue, 2014-04-01 at 13:13 +0800, Ben de Groot wrote: >>> >>> 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. >> >> 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? > > ++ > > I'm all for better solutions. I'm not in favor of abandoning > solutions that work moderately well in favor of talking about maybe > coming up with something better sometime down the road. > > The multilib eclass isn't a perfect solution. It will have issues in > concept, design, and implementation. These will come up from time to > time. I don't think it is productive that anytime any of these pop up > that we end up having a discussion about just reverting it entirely.
So why do we have this discussion? > By all means work on a competing solution. Get it working and > supported by portage. When the day comes that we want to endorse one > solution or the other as the preferred solution we can have that > discussion. That is hilariously funny. Wow. Now let's just continue to ignore the existing multilib-portage work so we can claim it's irrelevant, while shifting the conditions for accepting it whenever it is convenient, while silently adding the competing method in-tree so it's all decided now anyway ...
