1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
WHAT RULES I SHOULD FOLLOW WHEN I WANT TO WORK ON SOMETHING FOR KDE TEAM?
If you asked this question you are reading the right file.
KDE4 policies:
- NEVER EVER COMMIT NEW REVBUMPS NOR MAJOR CHANGES TO TREE DIRECTLY - ALWAYS USE overlay
first so that more pairs of eyes can spot issues. Especially anything in kde-base.
- append valid metadata.xml - not necessarily with <herd>kde</herd> if you're proxy
maintaining some ebuild. Never append ChangeLog because file/folder history is determined by commit log.
- NEVER EVER commit anything that can break metadata cache. Check every commit at least with repoman -v -d full!
- always separate DEPEND and RDEPEND properly (adding COMMON_DEPEND if needed)
- always use kde4-* eclasses. kde4-base for applications with main CMakeLists.txt in toplevel
source directory, kde4-meta for applications hidden deeper in source code directory structure
and requiring common CMakeLists.txt from toplevel directory.
See also KMEXTRA, KMEXTRACTONLY, KMCOMPILEONLY eclass variables.
NEVER FORGET TO INVOKE kde4-{base,meta}_${phase_function} when overriding ebuild phase!
- always report CMake issues about everything directly to upstream and backport their fix.
- never use -j1 in ebuilds. Always report the issue upstream and wait for the resolution or fix yourself
- double check the handbook useflag in your package. For kde4-meta style ebuilds - look for doc/${PN}
or similar directory. Sometimes application handbooks are not trivial to assign (for example
kde-base/khelpcenter ebuild), in such case ask Gentoo KDE team/HT members or contact upstream.
- think about adding debug USE flag to your package. Do not add debug USE flag for artwork-only and
python-only KDE packages. And don't forget to write metadata.xml entries for new local USE flags.
- do not enable USE flags by default (IUSE="+useflag") with no *good* reason. "Because I use it" is
not enough. If uncertain - discuss it with the rest of the team. USE flags that are considered as
commonly used, known to work and not pulling any dependencies, can be enabled by default right away.
- always check for linguas and add them to the KDE_LINGUAS variable.
- always fix automagic packages with macro_optional_ prefixing and report it upstream with patch.
- check your apps deps with dynlink-scanner.sh in Documentation/maintainers folder. Be aware, that this tool does not
return complete runtime dependency chain, still it will find most automagic linking dependencies.
- if you want our herd in the application and you are not Gentoo KDE team/HT member - ask us first.
- all kde4 and kde-live misc applications should be in SLOT="4". Feel free to fix packages that don't
follow this, and always add the correct blockers (be carefull not to block kde3 packages)
- if you revbump some snapshots of yet-not-released packages (like phonon, soprano, eigen etc), always ensure
it's visible *only* for those users that really need it and not for every ~arch users. For KDE dependencies,
there are kdedeps-${SLOT} sets created for this purpose. regenerate-files tool will mask those ebuilds
for everyone except those using kde-${SLOT} umask file helper, so those dependencies will be available
only for them.
- use the add_blocker function to add blocks. This ensures that the blocks are only added to RDEPEND.
Examples:
# Block all versions of kdelibs <=4.1.80
add_blocker kdelibs 4.1.80
# Block all versions of kdelibs <4.2.0
add_blocker kdelibs '<4.2.0'
# Block all versions of kdelibs <=4.2.80 or <=4.3.2 or <4.3.65 or <=9999, depending on SLOT
add_blocker kdelibs 4.2.80 4.3.2:4.3 '<4.3.65:4.4' 9999:live
# Block all versions of kde-menu (replaced by kdebase-menu)
add_blocker kde-menu
# Block all versions of kdelibs in slot :4.1 or prior
add_blocker kdelibs 4.1.50
For more details, read the comments in kde4-functions.eclass
- comment any new blockers you add
Commiting:
- always run repoman full on ebuild subtree you're working on before commiting *anything*
- try to keep one commit per change if possible. If more appropriate - one commit per feature.
- all commit messages must look like this:
[<category/pn>] <detailed message describing what you did>
Also append package version, when needed.
Examples:
[kde-base/kdelibs-4.2.3] Synced with tree: fixed bug #333452, removed unnecessary solid patch, added debug to IUSE.
[kde-base/kdelibs-4.2.3] Moved to tree.
- when you commit something related to existing bugzilla bug, add inOverlay to keywords to that bug,
so that developers know about it. Also add [overlay-name] to bug summary.
- if you refactor ebuild names in kde-base, *always* synchronize those changes in following locations
if applicable:
* sets/
* Documentation/package.keywords/
* Documentation/package.unmask/
Remember to do not edit autogenerated files, as your changes will be lost in next
regenerate-files tool run.
QA:
- keep ebuilds clean, look at recommended ebuild formatting rules below (obligatory for kde-base).
Use existing ebuilds (like kdelibs) for reference.
* sort dependencies alphabetically - it makes it easier to manage them later
>=app-misc/strigi-0.6.3[dbus,qt4]
dev-libs/libpcre
dev-libs/libxml2
* try to separate KEYWORDS and IUSE with some usually invariant variable (like LICENSE) - it makes
it easier to merge changes between live and tagged ebuilds using GUI diff/merge tools.
Always *avoid* merging/synchronizing ebuilds manually if possible - it's error prone.
Use kompare <srcfile> <destfile> for it.
KEYWORDS="~amd64 ~x86"
LICENSE="LGPL-2.1"
IUSE="3dnow acl alsa altivec bindist +bzip2 debug doc fam jpeg2k kerberos
mmx nls openexr +semantic-desktop spell sse sse2 ssl zeroconf"
* put blocks at the begin of RDEPEND section, !useflag? ( ) preferably before useflag? ( ) -
- it's easier to spot them when they're in expected location
RDEPEND="${DEPEND}
!kdeprefix? ( !dev-libs/libconvert )
"
* put optional dependencies after obligatory ones - again - improves readability
x11-proto/renderproto
xinerama? ( x11-proto/xineramaproto )
* avoid single line expressions - they are utterly unreadable
ssl? ( dev-libs/openssl )
zeroconf? (
|| (
net-dns/avahi[mdnsresponder-compat]
!bindist? ( net-misc/mDNSResponder )
)
)
* always indent dependencies with <tab> characters from new line (including other variable like
${COMMONDEPEND} may be exception here) and always break line *after* dependency - it makes it easier to
synchronize such deps semi-automatically between ebuilds using GUI diff/merge tools (less conflicts).
The same applies to PATCHES as well.
COMMONDEPEND="
>=app-misc/strigi-0.6.3[dbus,qt4]
"
# sth? ( dev/foo ) - re-add when in tree
DEPEND="${COMMONDEPEND}
doc? ( app-doc/doxygen )
nls? ( virtual/libintl )
"
PATCHES=(
"${FILESDIR}/dist/09_disable_debug_messages_if_not_explicitly_enabled.patch"
"${FILESDIR}/dist/20_use_dejavu_as_default_font.patch"
"${FILESDIR}/dist/23_solid_no_double_build.patch"
)
KDE 3 rules
- use kde-crazy overlay for your KDE3 experimental/testing work
- do what ever you want with one condition, make sure it really compiles/run
- feel free to commit patches without kde team ack if the above condition is checked
- all kde3 apps should have SLOT="3.5". Feel free to fix packages that don't follow this rule and don't
forget to add correct blockers
# NOT FOLLOWING THESE RULES WILL BE PUNISHED!
# no cookies for week!
|
