1 |
Well, it looks like I need to resend this... |
2 |
|
3 |
=== New Packages |
4 |
|
5 |
When adding new packages to the tree, only include KEYWORDS for archs on |
6 |
which you have actually tested. Note that "tested" does not equate to |
7 |
"compiled it with one particular combination of USE flags and didn't see |
8 |
any errors". Also, "you" does not mean "some random bloke on IRC who |
9 |
isn't a developer". |
10 |
|
11 |
If it's a user-submitted ebuild, don't assume that the submitter has |
12 |
done testing on lots of archs if they include lots of keywords -- |
13 |
chances are they just copied the KEYWORDS line in from another package. |
14 |
|
15 |
New packages shouldn't be keyworded stable on any arch directly. Always |
16 |
commit as ~arch and then stable later. |
17 |
|
18 |
Don't assume that upstream's list of "supported archs" correlates with |
19 |
Gentoo. We might not be using the same toolchain as them. They might be |
20 |
lying. They might just have tested one particular version twenty |
21 |
releases ago. |
22 |
|
23 |
The same applies for Debian's list of archs. That's only a compile test, |
24 |
and again they don't use the same toolchain. Oh, and they might have |
25 |
patches. |
26 |
|
27 |
If you're pretty sure that a package is arch-neutral, feel free to Cc: |
28 |
other archs on the bug after you've added the ebuild to the tree and ask |
29 |
them to consider keywording. Definitely do this if your package is cool; |
30 |
don't bother if it's some lame WindowMaker dockapp or if it has 'emacs' |
31 |
in the name. |
32 |
|
33 |
Just because it's a perl script does not mean it's arch-neutral. |
34 |
|
35 |
=== Adding in New Keywords |
36 |
|
37 |
Do not add in an ~arch keyword to an existing package unless you have |
38 |
tested on that arch. See earlier note for what "tested" means. |
39 |
|
40 |
Keywording bugs should be handled by the arch team in question who will |
41 |
do proper testing before adding in the keyword. We've had a fair number |
42 |
of keyword bugs where the user has only compile-tested the app and not |
43 |
tried to run it, or hasn't checked certain USE flag combinations. |
44 |
|
45 |
=== Moving an Ebuild from ~arch to arch |
46 |
|
47 |
DO NOT EVER MARK A PACKAGE STABLE on any arch on which you haven't |
48 |
tested. If you want to get an ebuild moved to stable, file a bug for the |
49 |
relevant archs or prod them repeatedly on IRC until they get sick of you |
50 |
and go and keyword the thing just to shut you up. Note that the second |
51 |
option doesn't work for people who know how to use /ignore or /kick. |
52 |
|
53 |
Arch teams: when moving from ~arch to arch on an actively maintained |
54 |
package where you're going ahead of the maintainer's arch, it's best to |
55 |
consult first. You don't necessarily have to follow the maintainer's |
56 |
advice, but at least listen to what they have to say. |
57 |
|
58 |
=== Version Bumps |
59 |
|
60 |
When doing a version bump, all existing arch keywords should be dropped |
61 |
to ~arch. Existing ~arch keywords should be left in. |
62 |
|
63 |
If a package is a really big change, it may be wise to drop keywords |
64 |
entirely for untested archs. You must file a bug if you do this. |
65 |
|
66 |
[ Exception: A few packages which have arch-specific patchsets and / or |
67 |
are very arch-sensitive (for example, some kernel sources) are handled |
68 |
differently. If you work with one of these packages, you should know how |
69 |
this works... ] |
70 |
|
71 |
If a new version introduces new dependencies which are not available on |
72 |
some archs, file a bug for the archs or ask on IRC before you do the |
73 |
bump. If you really need to get the ebuild added to the tree in a hurry, |
74 |
drop the keywords which are causing problems, but don't forget to file a |
75 |
bug letting the archs in question know what you've done. |
76 |
|
77 |
Do not remove keywords just to shut repoman up. If repoman is |
78 |
complaining about an arch which you didn't break yourself, first try a |
79 |
full cvs update. If it's still broken, file a bug for the broken arch. |
80 |
|
81 |
=== Sidenote on Dependencies |
82 |
|
83 |
Some optional dependencies pretty much have to be arch specific. Things |
84 |
which are binary-only or rely upon certain kernel features are the most |
85 |
common here. Although you *could* do DEPEND="!somearch? ( blah? ( |
86 |
libblah ) )", it's better to ask the arch in question to use.mask the |
87 |
blah flag. That way the USE flag will show up as being forced off on a |
88 |
given arch, rather than being selectable but not doing anything. |
89 |
|
90 |
=== Eclasses |
91 |
|
92 |
When making dependency changes in an eclass, don't forget to manually |
93 |
check that you're not breaking any archs. Repoman is no good here. It |
94 |
won't cry if, say, you update the eclass' DEPEND upon fooapp-config from |
95 |
>=1.5 to >=1.7 without checking that 1.7 is stable on all archs first. |
96 |
|
97 |
=== Removing Packages |
98 |
|
99 |
When tidying up, never remove the newest stable package for any arch. If |
100 |
you'd like to get a newer version marked stable on some archs, file a |
101 |
bug or ask on IRC. Be very very careful! Even Aron screwed this up once |
102 |
:) |
103 |
|
104 |
When tidying up ~arch, make sure you don't force a downgrade for any |
105 |
arch (unless of course you're deliberately doing so because of a nasty |
106 |
bug). |
107 |
|
108 |
=== Friendly Reminder |
109 |
|
110 |
Every time you screw up, you cause a lot of work for the arch teams. |
111 |
Spending an extra minute when making your change to get it right can |
112 |
save several hours of work from each of the arch teams. The arch teams |
113 |
are not there to clean up your mess. Do you really want to wake up and |
114 |
find http://dev.gentoo.org/~todd/blah.jpg staring you in the face? |
115 |
|
116 |
=== Summary |
117 |
|
118 |
* Don't keyword on archs on which you can't test |
119 |
|
120 |
* Don't drop keywords without letting arch teams know |
121 |
|
122 |
* Don't break dependencies |
123 |
|
124 |
* Be careful when tidying up |
125 |
|
126 |
-- |
127 |
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox) |
128 |
Mail : ciaranm at gentoo.org |
129 |
Web : http://dev.gentoo.org/~ciaranm |