On Sat, Jan 18, 2014 at 12:56:36AM +0100, Tom Wijsman wrote: > On Fri, 17 Jan 2014 18:28:41 +0000 > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > > On Fri, 17 Jan 2014 17:47:58 +0100 > > Tom Wijsman <tom...@gentoo.org> wrote: > > > Maybe we can let the package managers only perceive it as keyworded > > > or stable if all of its dependencies are keyworded or stable on the > > > architecture that the user runs. Then we can have repoman just > > > ignore checking dependencies' keywords when we keyword or stabilize > > > them. > > > > > > Not sure how implementable this idea is though...
Seems reasonable to me: it's a property of the tree per-arch, that can be calculated post-sync client-side, if all else fails, based on the metadata cache for standard ebuilds. So the resolver doesn't need to worry about it (as far as the resolver's concerned the ebuild is arch or ~arch according to CHOST.) > As a side note, I think we might want to name this anyarch... :) I agree, arch="any" makes a lot more sense. > > It's going to hurt for four reasons that I can think of right now. > > > > Firstly, things you think are "obviously portable" sometimes aren't. > > We could write a search for architecture dependent / specific code. > > > Secondly, users already get confused by "stable use masks". This is > > going to be even worse: users aren't going to understand why a noarch > > package isn't available for them. > > We can improve the output of the package manager to make this easier > to understand; one way is to clarify it, the other way is to just > replace it by the actual archictecture the user runs. Well, if we follow your idea, then the user won't know it's arch="any", since by the time resolution happens, it's marked stable or testing for the user's arch. So I don't really see the issue, though better info is always useful, and in case of problem, we'd likely want to be told it's an arch="~any" and what its dependencies are. But that's in the slowpath when there's a problem the resolver can't handle itself. > > Thirdly, you have to decide how to deal with long chains and cycles in > > noarch dependencies. > > > > Fourthly, the interaction with || deps is an awful mess. > > Yes, these are though problems to resolve; my mind came up with that > this idea needs recursion, hence the "not sure how implementable". These are standard dep resolution problems already, and given that the mangler is to consider it either arch or ~arch according to the user arch, and the state of its dependencies in the cache which can be worked out post-sync, this is exactly the same problem as the rest of the tree. So the rest of your mail appears to be a discussion of prior art. > If it is going to be a large share of the Portage tree we'll want to > look for another design or just not change how this works at all. Still not seeing the problem: perhaps we can see the roadblock in implementation. About the only issue I can see is trying to break an R/PDEPEND cycle, but again the question of whether its arch="any" is orthogonal, given your definition, so again that is covered by prior art. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
