On Mon, 21 Oct 2013 17:32:03 +0200 Tom Wijsman <tom...@gentoo.org> wrote:
> On Mon, 21 Oct 2013 15:50:34 +0200 > Jeroen Roovers <j...@gentoo.org> wrote: > > > On Sun, 20 Oct 2013 14:30:56 +0200 > > Tom Wijsman <tom...@gentoo.org> 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
