From: "Ulrich Müller" <ulm@gentoo.org>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] proj/devmanual:master commit in: keywording/
Date: Wed, 13 Oct 2021 13:42:07 +0000 (UTC) [thread overview]
Message-ID: <1634132435.42652857e3b5592b2001f13b041e66c341007ebe.ulm@gentoo> (raw)
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.
next reply other threads:[~2021-10-13 13:42 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 13:42 Ulrich Müller [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-07-30 7:59 [gentoo-commits] proj/devmanual:master commit in: keywording/ Ulrich Müller
2025-07-30 7:59 Ulrich Müller
2025-07-30 7:59 Ulrich Müller
2022-03-16 14:52 Sam James
2022-03-14 17:07 Matt Turner
2022-03-10 23:33 Sam James
2022-02-18 18:19 Sam James
2022-01-22 21:35 Sam James
2022-01-22 21:35 Sam James
2022-01-22 21:35 Sam James
2021-10-13 13:42 Ulrich Müller
2021-07-16 9:11 Ulrich Müller
2021-07-03 16:21 Ulrich Müller
2021-04-07 17:35 Ulrich Müller
2021-04-07 17:35 Ulrich Müller
2021-04-07 17:35 Ulrich Müller
2021-04-07 17:35 Ulrich Müller
2021-04-07 17:35 Ulrich Müller
2021-04-07 17:35 Ulrich Müller
2021-04-07 17:35 Ulrich Müller
2021-04-07 17:35 Ulrich Müller
2021-04-07 17:35 Ulrich Müller
2021-04-07 17:35 Ulrich Müller
2021-04-07 17:35 Ulrich Müller
2021-03-30 16:10 Ulrich Müller
2021-03-11 13:16 Ulrich Müller
2021-02-17 9:29 Ulrich Müller
2021-02-17 9:29 Ulrich Müller
2021-02-17 9:29 Ulrich Müller
2021-02-17 9:29 Ulrich Müller
2021-02-15 7:21 Ulrich Müller
2020-07-12 18:32 Ulrich Müller
2020-05-06 7:49 Ulrich Müller
2020-01-25 6:02 Ulrich Müller
2020-01-23 13:50 Ulrich Müller
2018-08-27 15:24 Göktürk Yüksek
2015-06-17 12:05 Ulrich Müller
2015-03-14 9:20 Markos Chandras
2013-02-16 0:03 Markos Chandras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1634132435.42652857e3b5592b2001f13b041e66c341007ebe.ulm@gentoo \
--to=ulm@gentoo.org \
--cc=gentoo-commits@lists.gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox