Gentoo Archives: gentoo-dev

From: Ciaran McCreesh <ciaranm@g.o>
To: gentoo-dev@l.g.o
Cc: tigger@g.o, citizen428@g.o, carlo@g.o, port001@g.o
Subject: [gentoo-dev] Proper KEYWORDing
Date: Thu, 26 Aug 2004 16:37:37
Message-Id: 20040826173433.14703c11@snowdrop.home
1 Well, it looks like I need to resend this...
3 === New Packages
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".
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.
15 New packages shouldn't be keyworded stable on any arch directly. Always
16 commit as ~arch and then stable later.
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.
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.
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.
33 Just because it's a perl script does not mean it's arch-neutral.
35 === Adding in New Keywords
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.
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.
45 === Moving an Ebuild from ~arch to arch
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.
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.
58 === Version Bumps
60 When doing a version bump, all existing arch keywords should be dropped
61 to ~arch. Existing ~arch keywords should be left in.
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.
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... ]
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.
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.
81 === Sidenote on Dependencies
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.
90 === Eclasses
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.
97 === Removing Packages
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 :)
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).
108 === Friendly Reminder
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 staring you in the face?
116 === Summary
118 * Don't keyword on archs on which you can't test
120 * Don't drop keywords without letting arch teams know
122 * Don't break dependencies
124 * Be careful when tidying up
126 --
127 Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
128 Mail : ciaranm at
129 Web :


Subject Author
Re: [gentoo-dev] Proper KEYWORD(-order)ing Mike Frysinger <vapier@g.o>