1 |
At this point I've made a couple suggestions, and developers have |
2 |
voiced either support or objections, and raised some good arguments |
3 |
either way. I'm hoping this email will summarize the three suggested |
4 |
approaches, their pros and cons, and we can eventually converge on a |
5 |
single solution. |
6 |
|
7 |
Proposed solutions: |
8 |
|
9 |
I. "stable" keyword |
10 |
------------------- |
11 |
pros |
12 |
- not tied to architecture keywords |
13 |
- not dependent on order of keywords |
14 |
- clearly nominates an ebuild as stable per the package |
15 |
maintainer without ambiguity |
16 |
- it's easy to tell which packages are following this standard |
17 |
and which ones are not |
18 |
|
19 |
cons |
20 |
- requires developer behavior change (marking ebuilds with |
21 |
"stable" keyword) |
22 |
- requires changes throughout the tree |
23 |
- uses another keyword |
24 |
- no indication of maintainer's arch (might be considered good |
25 |
or bad) |
26 |
- *requires* changes to portage on *user* systems to |
27 |
ignore/handle the "stable" keyword, otherwise portage spits |
28 |
out this error: |
29 |
IOError: Profile dir does not exist: |
30 |
/usr/local/home/agriffis/portage/profiles/default-stable-1.4 |
31 |
|
32 |
II. "marked keyword" indicates maintainer's arch |
33 |
------------------------------------------------ |
34 |
pros |
35 |
- not dependent on order of keywords |
36 |
- clearly nominates an ebuild as stable per the package |
37 |
maintainer without ambiguity |
38 |
- easy to tell which packages are following this standard and |
39 |
which are not |
40 |
- doesn't use a new keyword |
41 |
- calls out maintainer's arch(es) |
42 |
- does not require developer behavior change, because it can |
43 |
be handled automatically by ekeyword and repoman |
44 |
|
45 |
cons |
46 |
- requires changes throughout the tree |
47 |
- depends on architecture keywords |
48 |
- *requires* changes to portage on *user* systems to |
49 |
ignore/handle the new marking, otherwise portage spits out |
50 |
this error: |
51 |
IOError: Profile dir does not exist: |
52 |
/usr/local/home/agriffis/portage/profiles/default-+x86-1.4 |
53 |
|
54 |
III. first keyword marks maintainer's arch |
55 |
------------------------------------------ |
56 |
pros |
57 |
- takes advantage of existing order already present in *some* |
58 |
ebuilds |
59 |
- doesn't require changes throughout the tree, only in |
60 |
packages that aren't already following this standard |
61 |
- doesn't require any changes to portage on *user* systems, |
62 |
only developer systems (repoman and ekeyword changes) |
63 |
- does not require developer behavior change, because it can |
64 |
be handled automatically by ekeyword and repoman |
65 |
|
66 |
cons |
67 |
- dependent on order of keywords |
68 |
- not as unambiguous as the other two approaches |
69 |
- not easy to tell which packages are following this standard |
70 |
and which are not |
71 |
- doesn't use a new keyword |
72 |
- calls out only one of the maintainer's arch(es), so it might |
73 |
be misleading |
74 |
- keywords jump around in the list |
75 |
|
76 |
IV. <maintainernotes> in metadata.xml |
77 |
------------------------------------- |
78 |
This was suggested by Ciaran, and I'm including it for |
79 |
completeness, though I can't say I completely understand it. |
80 |
Ciaran's reasons were "much cleaner, provides much more |
81 |
information, doesn't imply meaning in an existing field which does |
82 |
not currently provide any information". Ciaran, do you feel like |
83 |
following up with a better explanation for how this would work? |
84 |
|
85 |
Instinctively I'm against it because it requires more work on the |
86 |
part of the package maintainer, and I'm trying to avoid the extra |
87 |
work all around. I *think* that suggestions I and II above both |
88 |
avoid the implication of meaning by making it explicit. |
89 |
Regarding providing "much more information", I'm concerned that |
90 |
could result in duplication of information between the bugs |
91 |
database and metadata.xml, a duplication that the package |
92 |
maintainer has to keep updated. |
93 |
|
94 |
All my objections stated :-) I would still like to hear about it |
95 |
if you think this is the better way to do things. It's possible |
96 |
that I'm missing a key point. |
97 |
|
98 |
Common attributes: |
99 |
|
100 |
- None of the proposed solutions attempts to enforce behavior. |
101 |
- Each provides a lightweight method of communication from the |
102 |
package maintainers to the arch maintainers. |
103 |
- Each can be recognized and maintained with ekeyword/repoman |
104 |
with very little developer behavior change. |
105 |
|
106 |
Personal leaning: |
107 |
|
108 |
I like solution II, "marked keyword", best because it clearly |
109 |
calls out the maintainer's tested arch(es). That seems like |
110 |
valuable information to me. Additionally it doesn't require |
111 |
developer behavior change, since ekeyword could determine |
112 |
automatically (1) you're the package maintainer, (2) you're |
113 |
marking a package stable, (3) what arch you're currently running. |
114 |
(Of course ekeyword would also support explicitly marking instead |
115 |
of automatic.) Not requiring developer behavior change these days |
116 |
is a lot easier than requiring it. We have a lot of developers, |
117 |
and they don't change behavior quickly or easily. |
118 |
|
119 |
The only thing I really dislike about the "marked keyword" |
120 |
approach is that it requires changes in the *user's* portage to |
121 |
handle the marking. But only solutions III and IV avoid that so |
122 |
far. |
123 |
|
124 |
I would like to hear feedback so that we can make a choice, do the |
125 |
necessary steps for implementation, and bring about a positive QA |
126 |
change in the portage tree. Hopefully along with an improvement in |
127 |
the package/arch-maintainer relationship :-) |
128 |
|
129 |
Regards, |
130 |
Aron |
131 |
|
132 |
-- |
133 |
Aron Griffis |
134 |
Gentoo Linux Developer |