Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc

[Jeroen Roovers]

On Mon, 21 Oct 2013 17:32:03 +0200
Tom Wijsman <TomWij@g.o> wrote:

> On Mon, 21 Oct 2013 15:50:34 +0200
> Jeroen Roovers <jer@g.o> wrote:
>
> > On Sun, 20 Oct 2013 14:30:56 +0200
> > Tom Wijsman <TomWij@g.o> wrote:
> >
> > There is no "instead".
>
> Why is there no "instead"?

"I planned to unkeyword the USE flags instead" - this is wrong. The
policy (see below for the link - you seem to have trouble finding it
every time I point it out) is to drop keywords (that is entries in the
KEYWORDS variable, see below for an extra explanation since you seem to
be confused as to what it means).

> > The default policy (did you read the devmanual yet?)
>
> Which policy are you referring to? (Did you refer me to anything?)

http://devmanual.gentoo.org/keywording/index.html

   "Sometimes you may need to remove a keyword because of new unresolved
    dependencies. If you do this, you *must* file a bug notifying the
    relevant arch teams."

> > is to DROP KEYWORDS (and let arch teams re-add them)
>
> Which is what I exactly did for the USE flags on most of the arches;
> and a bug was planned to be filed, such that they can decide on it.

You are apparently confusing "dropping keywords" (entries in the
KEYWORDS variable in an ebuild) with "masking USE flags". Why would you
do that? I know you are smarter than this.

> > -unless- that is really cumbersome (when you need to drop more and
> > more keywords as a result).
>
> Please do not make additional exceptions, we have enough of them.

What do you mean? This common sense policy has been in place for years.
If dropping one keyword breaks many (rev-)deps and is therefore not an
option, it's quite the norm to either file a keyword request bug well in
advance of anything in the tree breaking, or temporarily mask either
ebuilds or USE flags, generally or specifically for an arch profile,
and inform the arch teams.

> Right; bug reference added, I see no other problem here.

That should also tell you that it helps to inform arch teams by
filing a bug report -before- you drop keywords or mess up the profiles.

> Two entries will continue to be two entries; so, I do not see where
> the difference in work comes from. Can you now please explain the
> exception?

There is no exception. You've made that bit up.

The proper procedure is to ask arch teams to re-keyword the ebuild you
had to drop their keyword for. If that is impossible, several other
scenarios can be played out, such as use.masking to cover up a
deficiency in porting to said arch, dropping keywords for that arch
altogether, or whatever might work. The point is that you shouldn't be
making that decision - you just maintain the package, not the arch
profile, and you ran into a problem which you didn't propose they fix
- you just covered it all up.

The difference in work would amount to editing two files in the
profiles/ subdir per architecture you want to abuse profiles/ for
instead of asking their actual opinion, then later both undoing all
that work and simply changing the files that matter, the ebuilds and
auxiliary files (some 6 files in the example).

For an arch developer wanting to test if the new dep should really be
masked, or actually works just fine on his arch and should have been
keyworded long ago, the improper procedure involves both unmasking the
new dep in package.keywords as well as unmasking the USE flag on the
test system, and then reversing the profile change and adding the
keyword to the new dep.

With just the dropped keyword, everything is normally much simpler. I
don't see how you count up "entries" here - from experience re-adding
keywords is a lot easier than removing profile masks.


     jer