On Thu, Nov 14, 2013 at 7:30 AM, Patrick Lauer <patr...@gentoo.org> wrote: > > Apart from me masking a few things because portage couldn't figure out a > way to a consistent state, and all that ...
That is vague. It may be true, but it does nothing to help anybody understand what is going on. I haven't had to mask anything, which suggests that we're doing things differently. That isn't to say that you're doing things wrong, but it is hard to take complaints seriously when they're vague. > > I mean, not that we had lots of users in #gentoo WTFing all over the > place, or something. Oh wait, we did. Honestly, I wish that a news item went out before it was implemented. I'll agree that there was some end-user impact - I suddenly saw portage outputting requests to set ABI on a few packages due to dependency issues. However, when I followed portage's instructions as with any USE dependency issue everything "just worked." > > I have no idea how you think we can sort out anything with a pre-set > conclusion. What pre-set conclusion? Nobody said that you can't work on multilib in portage. Nobody said you couldn't put it in the tree either, but I would avoid namespace collision/etc unless done in a way that is compatible with the eclass-based solution. When we get to the point where we have two options I'd be all for making it possible for users to pick which one they want to use. > Apart from the maintainers that now have to figure out the funny bugs of > the in-tree work ... unlike a certain overlay. But I keep repeating > myself, which is redundantly redundant. I'll be the first to admit that I haven't seen these bugs, so I won't say they aren't severe. However, at least a few examples of the sorts of things that could go wrong wouldn't hurt. Again, this is vague. > So instead of figuring out bugs the proper way ... we let users hit > them? I feel tempted to use the letters "A" and "Q" together. > > Also, I could again redundantly point at a certain overlay. > > Oh well. I guess I should complain less and package.mask more to express > my feelings... Complaining isn't the problem. The issue is that complaints aren't helpful if they lack any detail or suggestions that are likely to be acted upon. Nobody is going to move the new eclass into an overlay, and it is unlikely that anybody is going to spend a year tweaking packages in an overlay just to find that they're all obsolete when it comes time to merge them into the main tree. Besides, it isn't like an overlay would get much testing on this scale anyway. Overlays are great places to work out issues on a small scale with a few packages if you have multiple developers involved. They don't really accomplish much when you scale up, because your overlay is always going to be out-of-date compared to the main tree. Honestly, I'm not trying to pick sides here. I just see complaints about very new features, and my sense is that if those features aren't working they should simply not be used. I don't think I have that variable set to anything but 64 on my stable amd64 system and I haven't seen any problems with it recently. If there are problems I'm certainly interested in hearing about them. Rich
