1 |
On Mon, 21 Oct 2013 18:31:43 +0200 |
2 |
Jeroen Roovers <jer@g.o> wrote: |
3 |
|
4 |
> "I planned to unkeyword the USE flags instead" - this is wrong. The |
5 |
> policy (see below for the link - you seem to have trouble finding it |
6 |
> every time I point it out) is to drop keywords (that is entries in the |
7 |
> KEYWORDS variable, see below for an extra explanation since you seem |
8 |
> to be confused as to what it means). |
9 |
> |
10 |
> > > The default policy (did you read the devmanual yet?) |
11 |
> > |
12 |
> > Which policy are you referring to? (Did you refer me to anything?) |
13 |
> |
14 |
> http://devmanual.gentoo.org/keywording/index.html |
15 |
> |
16 |
> "Sometimes you may need to remove a keyword because of new |
17 |
> unresolved dependencies. If you do this, you *must* file a bug |
18 |
> notifying the relevant arch teams." |
19 |
> |
20 |
> > > is to DROP KEYWORDS (and let arch teams re-add them) |
21 |
> > |
22 |
> > Which is what I exactly did for the USE flags on most of the arches; |
23 |
> > and a bug was planned to be filed, such that they can decide on it. |
24 |
> |
25 |
> You are apparently confusing "dropping keywords" (entries in the |
26 |
> KEYWORDS variable in an ebuild) with "masking USE flags". Why would |
27 |
> you do that? I know you are smarter than this. |
28 |
|
29 |
TL;DR: Clarified my misunderstanding, I agree now that I understand. |
30 |
|
31 |
Because the end result (a change in visibility) is mostly the same. |
32 |
|
33 |
I agree that "keywording" and "masking" are not the same; I however |
34 |
have considered that "masking is the scope of an arch" equals to |
35 |
"unkeywording" for that particular architecture. The difference in what |
36 |
happens towards the end result here is thus quite small; but now that |
37 |
you point it out, I do now understand that the words can carry quite a |
38 |
different meaning. A meaning that depends on how they are understood. |
39 |
|
40 |
Thanks you for highlighting that. |
41 |
|
42 |
> > > -unless- that is really cumbersome (when you need to drop more and |
43 |
> > > more keywords as a result). |
44 |
> > |
45 |
> > Please do not make additional exceptions, we have enough of them. |
46 |
> |
47 |
> What do you mean? This common sense policy has been in place for |
48 |
> years. If dropping one keyword breaks many (rev-)deps and is |
49 |
> therefore not an option, it's quite the norm to either file a keyword |
50 |
> request bug well in advance of anything in the tree breaking, or |
51 |
> temporarily mask either ebuilds or USE flags, generally or |
52 |
> specifically for an arch profile, and inform the arch teams. |
53 |
|
54 |
+1 Sorry, I was thinking about an end package as opposed to a library. |
55 |
|
56 |
> > Right; bug reference added, I see no other problem here. |
57 |
> |
58 |
> That should also tell you that it helps to inform arch teams by |
59 |
> filing a bug report -before- you drop keywords or mess up the |
60 |
> profiles. |
61 |
|
62 |
This is what I've almost always have done; but I went wrong here by off |
63 |
sourcing it this time to the proxy maintainer, will not do that again. |
64 |
|
65 |
> > Two entries will continue to be two entries; so, I do not see where |
66 |
> > the difference in work comes from. Can you now please explain the |
67 |
> > exception? |
68 |
> |
69 |
> There is no exception. You've made that bit up. |
70 |
|
71 |
http://gentoo.2317880.n4.nabble.com/best-way-to-use-profiles-and-package-use-mask-td16465.html |
72 |
|
73 |
From that thread I get that half of the people agree and that half of |
74 |
the people don't; looking at the package.use.mask I have seen non-arch |
75 |
members touch them from time to time, so while it might not |
76 |
necessarily be the exception I'm not so sure if it is the rule. |
77 |
|
78 |
Regardless of that view on it, I find your argument that you give |
79 |
below about the amount of files changed (adding + removing) and the |
80 |
difference between keywording and masking both requiring more work |
81 |
quite convincing; so I totally agree with you on that. |
82 |
|
83 |
> The proper procedure is to ask arch teams to re-keyword the ebuild you |
84 |
> had to drop their keyword for. If that is impossible, several other |
85 |
> scenarios can be played out, such as use.masking to cover up a |
86 |
> deficiency in porting to said arch, dropping keywords for that arch |
87 |
> altogether, or whatever might work. The point is that you shouldn't be |
88 |
> making that decision - you just maintain the package, not the arch |
89 |
> profile, and you ran into a problem which you didn't propose they fix |
90 |
> - you just covered it all up. |
91 |
> |
92 |
> The difference in work would amount to editing two files in the |
93 |
> profiles/ subdir per architecture you want to abuse profiles/ for |
94 |
> instead of asking their actual opinion, then later both undoing all |
95 |
> that work and simply changing the files that matter, the ebuilds and |
96 |
> auxiliary files (some 6 files in the example). |
97 |
> |
98 |
> For an arch developer wanting to test if the new dep should really be |
99 |
> masked, or actually works just fine on his arch and should have been |
100 |
> keyworded long ago, the improper procedure involves both unmasking the |
101 |
> new dep in package.keywords as well as unmasking the USE flag on the |
102 |
> test system, and then reversing the profile change and adding the |
103 |
> keyword to the new dep. |
104 |
> |
105 |
> With just the dropped keyword, everything is normally much simpler. I |
106 |
> don't see how you count up "entries" here - from experience re-adding |
107 |
> keywords is a lot easier than removing profile masks. |
108 |
|
109 |
I was reading your example from an user perspective the first time; in |
110 |
that perspective the user's work stays the same, I've mislead myself. :( |
111 |
|
112 |
Thank you very much for elaborating. |
113 |
|
114 |
-- |
115 |
With kind regards, |
116 |
|
117 |
Tom Wijsman (TomWij) |
118 |
Gentoo Developer |
119 |
|
120 |
E-mail address : TomWij@g.o |
121 |
GPG Public Key : 6D34E57D |
122 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |