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
|
WHAT RULES I SHOULD FOLLOW WHEN I WANT WORK ON SOMETHING FOR KDE TEAM?
If you asked this question you are reading right file.
So the rules are these:
- 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.
- 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
- doubleckeck the doc 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 useflag to your package. Do not add debug USE flag for artwork-only and
python-only KDE packages.
- 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 dylink scanner in maintainer 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.
- handle blocks carefully. Put blocks only in RDEPEND section and comment the reason for the block.
Block, if possible should contain specific version for the blocker. Below are most typical
scenarios for kde-base/ related blocks, your should use this as a pattern, unless you know what you're doing.
* ebuild rename not colliding with KDE3 ebuilds (see example kde-menu -> kdebase-menu)
!kdeprefix? ( !<old_cat>/<old_pkg>[-kdeprefix] )
kdeprefix? ( !<old_cat>/<old_pkg>:${SLOT} )
TODO
TODO ie. we introduce blocker for 4.1.87 then we add to the block !<cat/pn-4.1.87
TODO remember to use correct +-kdeprefix resolution
TODO !kdeprefix? ( !<cat/pn-version[kdeprefix-] )
TODO kdeprefix? ( !<cat/pn-version:slot[kdeprefix] )
TODO
Commiting:
- 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.
KDE 3:
- 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
# NOT FOLLOWING THIS RULES WILL BE PUNISHED!
# no cookies for week!
|
