On Mon, 21 Oct 2013 18:31:43 +0200 Jeroen Roovers <[email protected]> wrote:
> "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. TL;DR: Clarified my misunderstanding, I agree now that I understand. Because the end result (a change in visibility) is mostly the same. I agree that "keywording" and "masking" are not the same; I however have considered that "masking is the scope of an arch" equals to "unkeywording" for that particular architecture. The difference in what happens towards the end result here is thus quite small; but now that you point it out, I do now understand that the words can carry quite a different meaning. A meaning that depends on how they are understood. Thanks you for highlighting that. > > > -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. +1 Sorry, I was thinking about an end package as opposed to a library. > > 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. This is what I've almost always have done; but I went wrong here by off sourcing it this time to the proxy maintainer, will not do that again. > > 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. http://gentoo.2317880.n4.nabble.com/best-way-to-use-profiles-and-package-use-mask-td16465.html From that thread I get that half of the people agree and that half of the people don't; looking at the package.use.mask I have seen non-arch members touch them from time to time, so while it might not necessarily be the exception I'm not so sure if it is the rule. Regardless of that view on it, I find your argument that you give below about the amount of files changed (adding + removing) and the difference between keywording and masking both requiring more work quite convincing; so I totally agree with you on that. > 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. I was reading your example from an user perspective the first time; in that perspective the user's work stays the same, I've mislead myself. :( Thank you very much for elaborating. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : [email protected] GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
