commit: 42652857e3b5592b2001f13b041e66c341007ebe
Author: Joonas Niilola <juippis <AT> gentoo <DOT> org>
AuthorDate: Sun Oct 10 10:03:33 2021 +0000
Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org>
CommitDate: Wed Oct 13 13:40:35 2021 +0000
URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=42652857
keywording: wrap text at 80 chars
Signed-off-by: Joonas Niilola <juippis <AT> gentoo.org>
Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org>
keywording/text.xml | 71 +++++++++++++++++++++++++++--------------------------
1 file changed, 36 insertions(+), 35 deletions(-)
diff --git a/keywording/text.xml b/keywording/text.xml
index 159d746..74bca5d 100644
--- a/keywording/text.xml
+++ b/keywording/text.xml
@@ -5,10 +5,10 @@
<body>
<note>
-<e>Terminology</e>: The term 'package' refers to an entire directory, for
example
-<c>app-editors/vim</c> <d /> it does <e>not</e> refer to a specific version.
The terms
-'ebuild' or 'package version' are used when this meaning is intended. This
-distinction is important.
+<e>Terminology</e>: The term 'package' refers to an entire directory, for
+example <c>app-editors/vim</c> <d /> it does <e>not</e> refer to a specific
+version. The terms 'ebuild' or 'package version' are used when this meaning is
+intended. This distinction is important.
</note>
<p>
@@ -41,8 +41,8 @@ The different levels of keyword are:
<c>arch</c> (<c>x86</c>, <c>ppc-macos</c>) ("stable")
</dt>
<dd>
- Both the package version <e>and</e> the ebuild are widely tested, known to
work
- and not have any serious issues on the indicated platform.
+ Both the package version <e>and</e> the ebuild are widely tested, known to
+ work and not have any serious issues on the indicated platform.
</dd>
<dt>
<c>~arch</c> (<c>~x86</c>, <c>~ppc-macos</c>) ("testing")
@@ -72,9 +72,10 @@ The different levels of keyword are:
</dl>
<p>
-The <c>-*</c> keyword is special. It is used to indicate package versions
which are
-not worth trying to test on unlisted arches. For example, a binary-only package
-which is only supported upstream on <c>ppc</c> and <c>x86</c> might use:
+The <c>-*</c> keyword is special. It is used to indicate package versions which
+are not worth trying to test on unlisted arches. For example, a binary-only
+package which is only supported upstream on <c>ppc</c> and <c>x86</c> might
+use:
</p>
<codesample lang="ebuild">
@@ -103,23 +104,23 @@ do not specify a <c>KEYWORDS</c> variable.
<body>
<p>
-An ebuild <b>must not</b> depend upon any package that is of a lower keyword
level
-than itself. For example, if <c>foo-1.2</c> depends upon <c>bar-1.2</c>, and
-<c>bar-1.2</c> is <c>~x86</c>, then <c>foo-1.2</c> must <b>not</b> be marked
stable on
-<c>x86</c> unless <c>bar-1.2</c> is also stabilised.
+An ebuild <b>must not</b> depend upon any package that is of a lower keyword
+level than itself. For example, if <c>foo-1.2</c> depends upon <c>bar-1.2</c>,
+and <c>bar-1.2</c> is <c>~x86</c>, then <c>foo-1.2</c> must <b>not</b> be
marked
+stable on <c>x86</c> unless <c>bar-1.2</c> is also stabilised.
</p>
<p>
-You may assume that if a user accepts <c>~arch</c> for a given arch then they
also
-accept <c>arch</c>.
+You may assume that if a user accepts <c>~arch</c> for a given arch then they
+also accept <c>arch</c>.
</p>
<p>
-For optional dependencies, all <e>possible</e> dependencies must satisfy the
above.
-Note that certain <c>USE</c> flags can be forcibly disabled on a per-profile
basis
-<d /> talk to the arch teams if you require this. For either-or dependencies,
<e>at
-least one</e> of the options must be of equal or better visibility than the
-package in question.
+For optional dependencies, all <e>possible</e> dependencies must satisfy the
+above. Note that certain <c>USE</c> flags can be forcibly disabled on a
+per-profile basis <d /> talk to the arch teams if you require this. For
+either-or dependencies, <e>at least one</e> of the options must be of equal or
+better visibility than the package in question.
</p>
</body>
@@ -139,10 +140,10 @@ packages.
<p>
The only time it is acceptable for a user to see the <c>Possibly a DEPEND
-problem</c> error message is if they have manually changed visibility levels
for a
-package (for example, through <c>/etc/portage/</c>) and have missed a
dependency.
-<b>You should never commit a change which could cause this error to appear on a
-user system</b>.
+problem</c> error message is if they have manually changed visibility levels
for
+a package (for example, through <c>/etc/portage/</c>) and have missed a
+dependency. <b>You should never commit a change which could cause this error to
+appear on a user system</b>.
</p>
</body>
@@ -162,12 +163,12 @@ a keywording bug instead for non-<c>amd64</c>/<c>x86</c>.
<p>
Do <b>not</b> assume that your package works on all architectures. Do
<b>not</b>
-assume that user submitted ebuilds will have correct <c>KEYWORDS</c> <d />
chances are
-they just copied from somewhere else. Do <b>not</b> assume that upstream's
-'supported architectures' list is correct. Do <b>not</b> assume that because
your
-code is written in Perl / Python / Java / whatever that it will run on other
-arches (there is at least one case of a <c>vim</c> script which only worked on
-<c>x86</c>).
+assume that user submitted ebuilds will have correct <c>KEYWORDS</c> <d />
+chances are they just copied from somewhere else. Do <b>not</b> assume that
+upstream's 'supported architectures' list is correct. Do <b>not</b> assume that
+because your code is written in Perl / Python / Java / whatever that it will
run
+on other arches (there is at least one case of a <c>vim</c> script which only
+worked on <c>x86</c>).
</p>
<p>
@@ -327,8 +328,8 @@ for further details):
The package version must be widely tested.
</li>
<li>
- If the package is a library, it should be known not to break any package
which
- depends upon it.
+ If the package is a library, it should be known not to break any package
+ which depends upon it.
</li>
</ul>
@@ -443,9 +444,9 @@ any given keyword level on any profile. The aim here is:
<ul>
<li>
Never to force a downgrade. (Exception: occasionally you really do want to
- force a downgrade, for example if the newly committed <c>foo-1.3</c> turns
out
- to be badly broken and that making everyone downgrade to <c>foo-1.2</c> is
the
- better option. This is rare.)
+ force a downgrade, for example if the newly committed <c>foo-1.3</c> turns
+ out to be badly broken and that making everyone downgrade to <c>foo-1.2</c>
+ is the better option. This is rare.)
</li>
<li>
Do not break any existing dependencies.
