[gentoo-dev] arch="any" (Re: rfc: revisiting our stabilization policy)

[Steven J. Long]

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.mccreesh@××××××××××.com> wrote:
>
> > On Fri, 17 Jan 2014 17:47:58 +0100
> > Tom Wijsman <TomWij@g.o> 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 ;-)