On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer <[email protected]> wrote: > > So just "fix it as problems appear and/or we have some spare time" ...
Have any problems appeared that impact anybody who hasn't tried to take advantage of the new multilib features (ie modified their config files/etc)? > > Well, you accidentally cut out all references to TommyD's work again. > Almost as if you don't even want to discuss a working proper solution > that just doesn't have the ego hammering it in ... We get it - there are two competing approaches to multilib... That's perfectly fine - we can sort out which one works better once they both work. It would be more of a concern if maintainers were being asked to maintain things twice, but as far as I'm aware the developers of each of the competing approaches have been doing most of the work themselves. Of course, there could be issues I simply haven't heard of. > There's this thing called overlay ;) > Once you have everything prepared commit it all masked. > A few days later if there's no obvious bug reports unmask it and duck. I'm not sure an overlay is a good solution for a tree-wide change that will take months to roll out. It is great for testing the core features with a small testing group, but the implementation is always going to have to hit the whole tree and all its consumers with little formal testing at that scale. I guess my main question is what exactly is broken? I haven't heard of any large-scale problems with the new multilib rollout. I'm sure if I went looking for bugs I'd find them, but that's pretty much par-for-the-course for Gentoo. If I go install the latest gcc the day after it gets added to the tree and enable some new flag that was just introduced I'm going to find lots of packages that break. That doesn't mean that the new GCC wasn't ready for the tree - just that I went looking for trouble, found it, and now I have the opportunity to help out by filing bugs if what I actually did was reasonable. Rich
