| 1 |
commit: 42652857e3b5592b2001f13b041e66c341007ebe |
| 2 |
Author: Joonas Niilola <juippis <AT> gentoo <DOT> org> |
| 3 |
AuthorDate: Sun Oct 10 10:03:33 2021 +0000 |
| 4 |
Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org> |
| 5 |
CommitDate: Wed Oct 13 13:40:35 2021 +0000 |
| 6 |
URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=42652857 |
| 7 |
|
| 8 |
keywording: wrap text at 80 chars |
| 9 |
|
| 10 |
Signed-off-by: Joonas Niilola <juippis <AT> gentoo.org> |
| 11 |
Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org> |
| 12 |
|
| 13 |
keywording/text.xml | 71 +++++++++++++++++++++++++++-------------------------- |
| 14 |
1 file changed, 36 insertions(+), 35 deletions(-) |
| 15 |
|
| 16 |
diff --git a/keywording/text.xml b/keywording/text.xml |
| 17 |
index 159d746..74bca5d 100644 |
| 18 |
--- a/keywording/text.xml |
| 19 |
+++ b/keywording/text.xml |
| 20 |
@@ -5,10 +5,10 @@ |
| 21 |
<body> |
| 22 |
|
| 23 |
<note> |
| 24 |
-<e>Terminology</e>: The term 'package' refers to an entire directory, for example |
| 25 |
-<c>app-editors/vim</c> <d /> it does <e>not</e> refer to a specific version. The terms |
| 26 |
-'ebuild' or 'package version' are used when this meaning is intended. This |
| 27 |
-distinction is important. |
| 28 |
+<e>Terminology</e>: The term 'package' refers to an entire directory, for |
| 29 |
+example <c>app-editors/vim</c> <d /> it does <e>not</e> refer to a specific |
| 30 |
+version. The terms 'ebuild' or 'package version' are used when this meaning is |
| 31 |
+intended. This distinction is important. |
| 32 |
</note> |
| 33 |
|
| 34 |
<p> |
| 35 |
@@ -41,8 +41,8 @@ The different levels of keyword are: |
| 36 |
<c>arch</c> (<c>x86</c>, <c>ppc-macos</c>) ("stable") |
| 37 |
</dt> |
| 38 |
<dd> |
| 39 |
- Both the package version <e>and</e> the ebuild are widely tested, known to work |
| 40 |
- and not have any serious issues on the indicated platform. |
| 41 |
+ Both the package version <e>and</e> the ebuild are widely tested, known to |
| 42 |
+ work and not have any serious issues on the indicated platform. |
| 43 |
</dd> |
| 44 |
<dt> |
| 45 |
<c>~arch</c> (<c>~x86</c>, <c>~ppc-macos</c>) ("testing") |
| 46 |
@@ -72,9 +72,10 @@ The different levels of keyword are: |
| 47 |
</dl> |
| 48 |
|
| 49 |
<p> |
| 50 |
-The <c>-*</c> keyword is special. It is used to indicate package versions which are |
| 51 |
-not worth trying to test on unlisted arches. For example, a binary-only package |
| 52 |
-which is only supported upstream on <c>ppc</c> and <c>x86</c> might use: |
| 53 |
+The <c>-*</c> keyword is special. It is used to indicate package versions which |
| 54 |
+are not worth trying to test on unlisted arches. For example, a binary-only |
| 55 |
+package which is only supported upstream on <c>ppc</c> and <c>x86</c> might |
| 56 |
+use: |
| 57 |
</p> |
| 58 |
|
| 59 |
<codesample lang="ebuild"> |
| 60 |
@@ -103,23 +104,23 @@ do not specify a <c>KEYWORDS</c> variable. |
| 61 |
<body> |
| 62 |
|
| 63 |
<p> |
| 64 |
-An ebuild <b>must not</b> depend upon any package that is of a lower keyword level |
| 65 |
-than itself. For example, if <c>foo-1.2</c> depends upon <c>bar-1.2</c>, and |
| 66 |
-<c>bar-1.2</c> is <c>~x86</c>, then <c>foo-1.2</c> must <b>not</b> be marked stable on |
| 67 |
-<c>x86</c> unless <c>bar-1.2</c> is also stabilised. |
| 68 |
+An ebuild <b>must not</b> depend upon any package that is of a lower keyword |
| 69 |
+level than itself. For example, if <c>foo-1.2</c> depends upon <c>bar-1.2</c>, |
| 70 |
+and <c>bar-1.2</c> is <c>~x86</c>, then <c>foo-1.2</c> must <b>not</b> be marked |
| 71 |
+stable on <c>x86</c> unless <c>bar-1.2</c> is also stabilised. |
| 72 |
</p> |
| 73 |
|
| 74 |
<p> |
| 75 |
-You may assume that if a user accepts <c>~arch</c> for a given arch then they also |
| 76 |
-accept <c>arch</c>. |
| 77 |
+You may assume that if a user accepts <c>~arch</c> for a given arch then they |
| 78 |
+also accept <c>arch</c>. |
| 79 |
</p> |
| 80 |
|
| 81 |
<p> |
| 82 |
-For optional dependencies, all <e>possible</e> dependencies must satisfy the above. |
| 83 |
-Note that certain <c>USE</c> flags can be forcibly disabled on a per-profile basis |
| 84 |
-<d /> talk to the arch teams if you require this. For either-or dependencies, <e>at |
| 85 |
-least one</e> of the options must be of equal or better visibility than the |
| 86 |
-package in question. |
| 87 |
+For optional dependencies, all <e>possible</e> dependencies must satisfy the |
| 88 |
+above. Note that certain <c>USE</c> flags can be forcibly disabled on a |
| 89 |
+per-profile basis <d /> talk to the arch teams if you require this. For |
| 90 |
+either-or dependencies, <e>at least one</e> of the options must be of equal or |
| 91 |
+better visibility than the package in question. |
| 92 |
</p> |
| 93 |
|
| 94 |
</body> |
| 95 |
@@ -139,10 +140,10 @@ packages. |
| 96 |
|
| 97 |
<p> |
| 98 |
The only time it is acceptable for a user to see the <c>Possibly a DEPEND |
| 99 |
-problem</c> error message is if they have manually changed visibility levels for a |
| 100 |
-package (for example, through <c>/etc/portage/</c>) and have missed a dependency. |
| 101 |
-<b>You should never commit a change which could cause this error to appear on a |
| 102 |
-user system</b>. |
| 103 |
+problem</c> error message is if they have manually changed visibility levels for |
| 104 |
+a package (for example, through <c>/etc/portage/</c>) and have missed a |
| 105 |
+dependency. <b>You should never commit a change which could cause this error to |
| 106 |
+appear on a user system</b>. |
| 107 |
</p> |
| 108 |
|
| 109 |
</body> |
| 110 |
@@ -162,12 +163,12 @@ a keywording bug instead for non-<c>amd64</c>/<c>x86</c>. |
| 111 |
|
| 112 |
<p> |
| 113 |
Do <b>not</b> assume that your package works on all architectures. Do <b>not</b> |
| 114 |
-assume that user submitted ebuilds will have correct <c>KEYWORDS</c> <d /> chances are |
| 115 |
-they just copied from somewhere else. Do <b>not</b> assume that upstream's |
| 116 |
-'supported architectures' list is correct. Do <b>not</b> assume that because your |
| 117 |
-code is written in Perl / Python / Java / whatever that it will run on other |
| 118 |
-arches (there is at least one case of a <c>vim</c> script which only worked on |
| 119 |
-<c>x86</c>). |
| 120 |
+assume that user submitted ebuilds will have correct <c>KEYWORDS</c> <d /> |
| 121 |
+chances are they just copied from somewhere else. Do <b>not</b> assume that |
| 122 |
+upstream's 'supported architectures' list is correct. Do <b>not</b> assume that |
| 123 |
+because your code is written in Perl / Python / Java / whatever that it will run |
| 124 |
+on other arches (there is at least one case of a <c>vim</c> script which only |
| 125 |
+worked on <c>x86</c>). |
| 126 |
</p> |
| 127 |
|
| 128 |
<p> |
| 129 |
@@ -327,8 +328,8 @@ for further details): |
| 130 |
The package version must be widely tested. |
| 131 |
</li> |
| 132 |
<li> |
| 133 |
- If the package is a library, it should be known not to break any package which |
| 134 |
- depends upon it. |
| 135 |
+ If the package is a library, it should be known not to break any package |
| 136 |
+ which depends upon it. |
| 137 |
</li> |
| 138 |
</ul> |
| 139 |
|
| 140 |
@@ -443,9 +444,9 @@ any given keyword level on any profile. The aim here is: |
| 141 |
<ul> |
| 142 |
<li> |
| 143 |
Never to force a downgrade. (Exception: occasionally you really do want to |
| 144 |
- force a downgrade, for example if the newly committed <c>foo-1.3</c> turns out |
| 145 |
- to be badly broken and that making everyone downgrade to <c>foo-1.2</c> is the |
| 146 |
- better option. This is rare.) |
| 147 |
+ force a downgrade, for example if the newly committed <c>foo-1.3</c> turns |
| 148 |
+ out to be badly broken and that making everyone downgrade to <c>foo-1.2</c> |
| 149 |
+ is the better option. This is rare.) |
| 150 |
</li> |
| 151 |
<li> |
| 152 |
Do not break any existing dependencies. |
Archives