|
Lines 5-45
Link Here
|
| 5 |
|
5 |
|
| 6 |
<body> |
6 |
<body> |
| 7 |
<p> |
7 |
<p> |
| 8 |
Ebuilds may have a Gentoo revision number associated with them. This is a |
8 |
Ebuilds may have a revision suffix of the form <c>-rX</c>, where the |
| 9 |
<c>-rX</c> suffix, where <c>X</c> is an integer <d/> see <uri |
9 |
Gentoo <e>revision number</e> <c>X</c> is a natural number <d/> see |
| 10 |
link="::ebuild-writing/file-format#File Naming Rules"/>. This |
10 |
<uri link="::ebuild-writing/file-format#File Naming Rules"/>. The |
| 11 |
component must only be used for Gentoo changes, not upstream releases. By |
11 |
revision number indicates the <e>ebuild version</e> and is |
| 12 |
default, <c>-r0</c> is implied. |
12 |
independent of the upstream package version. A default revision |
|
|
13 |
number of <c>0</c> is implied. New revisions of existing ebuilds |
| 14 |
are often called "revision bumps," or "revbumps" |
| 15 |
for short. |
| 13 |
</p> |
16 |
</p> |
| 14 |
|
17 |
|
| 15 |
<p> |
18 |
<p> |
| 16 |
Ebuilds should have their <c>-rX</c> incremented whenever a change is made which |
19 |
Increment the revision number whenever you change an ebuild. New |
| 17 |
will make a substantial difference to what gets installed by the package <d/> by |
20 |
revisions are subject to the <uri link="::keywording#Keywording on |
| 18 |
substantial, we generally mean "something for which many users would want to |
21 |
Upgrades">keyword policy for upgrades</uri>, and should be based on |
| 19 |
upgrade". This is usually for bugfixes. |
22 |
the <e>previous</e> revision so that fixes are not accidentally |
| 20 |
For any such revision bump, the new ebuild should be based on the |
23 |
dropped. A few exceptions to this rule are outlined below. If you |
| 21 |
previous revision to ensure that fixes aren't dropped accidentally. |
24 |
are unsure, increment the revision number. |
| 22 |
</p> |
25 |
</p> |
| 23 |
|
26 |
|
| 24 |
<p> |
27 |
<warning> |
| 25 |
Simple compile fixes do <b>not</b> warrant a revision bump; this is because they do |
28 |
These exceptions do not apply to stable ebuilds. Only under |
| 26 |
not affect the installed package for users who already managed to compile it. |
29 |
<strong>exceptional</strong> circumstances should you modify an |
| 27 |
Small documentation fixes are also usually not grounds for a new revision. |
30 |
ebuild that is marked stable on any arch. |
| 28 |
In particular, this applies if the package has a substantial compilation |
31 |
</warning> |
| 29 |
time; developers should use their best judgement in these circumstances. |
|
|
| 30 |
</p> |
| 31 |
|
| 32 |
<important> |
| 33 |
For ebuilds marked stable on at least one arch, only trivial edits can be made |
| 34 |
without a bump (e.g. typo fixes in elog messages). Even simple changes may |
| 35 |
result in a breakage. <b>Modifying stable ebuilds should be avoided.</b> |
| 36 |
</important> |
| 37 |
|
32 |
|
| 38 |
<p> |
33 |
<p> |
| 39 |
When doing a revision bump, the usual rules about dropping to <c>~arch</c> apply. |
34 |
In the following cases, you may modify an ebuild in-place: |
| 40 |
See <uri link="::keywording#Keywording on Upgrades"/>. |
|
|
| 41 |
</p> |
35 |
</p> |
| 42 |
|
36 |
|
|
|
37 |
<ul> |
| 38 |
<li> |
| 39 |
Fixes for compilation failures. These do not affect users |
| 40 |
who have already managed to build the package, so there's no |
| 41 |
reason to force the package to be rebuilt. |
| 42 |
</li> |
| 43 |
<li> |
| 44 |
Changes to comments. |
| 45 |
</li> |
| 46 |
<li> |
| 47 |
Trivial fixes (for example, typos) in elog messages. |
| 48 |
</li> |
| 49 |
<li> |
| 50 |
Modification of build-time dependencies. Use this exception |
| 51 |
sparingly and only if the package takes an extremely long time to |
| 52 |
compile. |
| 53 |
</li> |
| 54 |
</ul> |
| 55 |
|
| 43 |
</body> |
56 |
</body> |
| 44 |
</chapter> |
57 |
</chapter> |
| 45 |
</guide> |
58 |
</guide> |
| 46 |
- |
|
|
