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. 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. Dirty hack or not the multilib eclass seems to be working fairly well in practice, especially considering just how big a change it is. The emul-linux packages were an even dirtier hack and those worked well for a decade. Progress can be incremental. Rich
