commit: 143db50760758ca340cc88f41f44955d4d16e1e7
Author: Ulrich Müller <ulm <AT> gentoo <DOT> org>
AuthorDate: Thu Dec 26 19:27:30 2019 +0000
Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org>
CommitDate: Thu Dec 26 20:40:27 2019 +0000
URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=143db507
Remove all p elements below dd.
Where necessary, use multiple dd elements instead.
Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org>
appendices/common-problems/text.xml | 6 ------
appendices/contributing/text.xml | 31 +++++++++++++------------------
appendices/further-reading/text.xml | 6 ------
archs/amd64/text.xml | 12 +++---------
ebuild-writing/eapi/text.xml | 12 ++++++------
general-concepts/tree/text.xml | 25 ++++---------------------
keywording/text.xml | 8 --------
tools-reference/tr/text.xml | 16 +++++-----------
8 files changed, 31 insertions(+), 85 deletions(-)
diff --git a/appendices/common-problems/text.xml
b/appendices/common-problems/text.xml
index 3af479b..430e74b 100644
--- a/appendices/common-problems/text.xml
+++ b/appendices/common-problems/text.xml
@@ -56,36 +56,30 @@ in use, there are various alternatives:
<c>sed</c>, <c>awk</c>, <c>grep</c>, <c>egrep</c>, <c>cut</c> etc
</dt>
<dd>
- <p>
Usually when any of the above are used in global scope, it is to manipulate
a version or program name string. These should be avoided in favour of
pure <c>bash</c> constructs. The <c>eapi7-ver</c> eclass is often of use
here.
See <uri link="::ebuild-writing/variables/#Version and Name Formatting
Issues"/>,
<c>man eapi7-ver.eclass</c> and <uri
link="::tools-reference/bash/#Bash Variable Manipulation"/>.
- </p>
</dd>
<dt>
<c>has_version</c>, <c>best_version</c>
</dt>
<dd>
- <p>
Calls to either of these globally indicates a serious problem. You must
<b>not</b>
have metadata varying based upon system-dependent information <d/> see
<uri link="::general-concepts/portage-cache/"/>. You should rewrite your
ebuilds
to correctly use dependencies.
- </p>
</dd>
<dt>
<c>python</c>, <c>perl</c> etc
</dt>
<dd>
- <p>
Ebuilds are <c>bash</c> scripts. Offloading anything you don't know how to
do
in <c>bash</c> onto another language is not acceptable <d/> if nothing
else,
because not all users will always have a full system when ebuilds are
sourced.
- </p>
</dd>
</dl>
diff --git a/appendices/contributing/text.xml b/appendices/contributing/text.xml
index 4b65c41..d17205a 100644
--- a/appendices/contributing/text.xml
+++ b/appendices/contributing/text.xml
@@ -81,34 +81,29 @@ really should first examine the GuideXML guide in a
reasonable amount of depth.
Indentation
</dt>
<dd>
- <p>
- Indent when needed <d/> you should not indent any section flow elements
such as
- <c><subsection></c> but do indent tables, lists and definition
lists.
- Do <e>not</e> indent text in ordinary paragraph blocks.
- </p>
+ Indent when needed <d/> you should not indent any section flow elements
+ such as <c><subsection></c> but do indent tables, lists and
+ definition lists. Do <e>not</e> indent text in ordinary paragraph blocks.
</dd>
<dt>
Code Samples
</dt>
<dd>
- <p>
- You can use the normal GuideXML tag <c><pre></c> when you need no
syntax
- highlighting. When you need syntax highlighting use the
<c><codesample></c>
- tag along with a <c>lang</c> attribute <d/> usually you want this to be
set to
- <c>ebuild</c> to syntax highlight ebuild code snippets.
- </p>
+ You can use the normal GuideXML tag <c><pre></c> when you need
+ no syntax highlighting. When you need syntax highlighting use the
+ <c><codesample></c> tag along with a <c>lang</c> attribute <d/>
+ usually you want this to be set to <c>ebuild</c> to syntax highlight ebuild
+ code snippets.
</dd>
<dt>
Hierarchy
</dt>
<dd>
- <p>
- The whole document is organized as a tree. Each directory can contain one
- document. Each document can inherit multiple sub-documents using the
- <c><include></c> flag. You <b>must</b> ensure that the <c>self</c>
tag
- in each document correctly points to the relative path of the document
from
- the root node so that the tree-walking algorithms work correctly.
- </p>
+ The whole document is organized as a tree. Each directory can contain
+ one document. Each document can inherit multiple sub-documents using the
+ <c><include></c> flag. You <b>must</b> ensure that the <c>self</c>
+ tag in each document correctly points to the relative path of the document
+ from the root node so that the tree-walking algorithms work correctly.
</dd>
</dl>
diff --git a/appendices/further-reading/text.xml
b/appendices/further-reading/text.xml
index d48277c..0a658f6 100644
--- a/appendices/further-reading/text.xml
+++ b/appendices/further-reading/text.xml
@@ -19,12 +19,10 @@ recommendations, not padding designed to make this document
look important.
Mastering Regular Expressions
</dt>
<dd>
- <p>
"Mastering Regular Expressions" by Jeffrey E. F. Friedl (O'Reilly,
ISBN 0-596-00289-0) is <b>the</b> book on regular expressions. Very
readable and
devoid of the usual mathematical jargon that tends to fill up these kinds
of
books. <uri link="http://www.oreilly.com/catalog/regex2/";>Publisher's
page</uri>
- </p>
</dd>
</dl>
@@ -40,21 +38,17 @@ recommendations, not padding designed to make this document
look important.
Making Packager-Friendly Software
</dt>
<dd>
- <p>
<uri
link="http://www.onlamp.com/pub/a/onlamp/2005/03/31/packaging.html";>Making
Packager-Friendly Software</uri> by Julio M. Merino Vidal describes
various things
that can be done by upstream software providers to make life easy for the
distribution people (that means you).
- </p>
</dd>
<dt>
How to Report Bugs Effectively
</dt>
<dd>
- <p>
<uri link="https://www.chiark.greenend.org.uk/~sgtatham/bugs.html";>How to
Report Bugs
Effectively</uri> by Simon Tatham is a good overview of effective bug
reporting.
- </p>
</dd>
</dl>
diff --git a/archs/amd64/text.xml b/archs/amd64/text.xml
index 392999b..0f75426 100644
--- a/archs/amd64/text.xml
+++ b/archs/amd64/text.xml
@@ -269,25 +269,19 @@ configurations.
d
</dt>
<dd>
- <p>
- Directory containing mixed-bit objects
- </p>
+ Directory containing mixed-bit objects
</dd>
<dt>
dXX
</dt>
<dd>
- <p>
- Directory containing XXbit objects
- </p>
+ Directory containing XXbit objects
</dd>
<dt>
l->foo
</dt>
<dd>
- <p>
- Link to foo
- </p>
+ Link to foo
</dd>
</dl>
diff --git a/ebuild-writing/eapi/text.xml b/ebuild-writing/eapi/text.xml
index 3f9590d..cb49e35 100644
--- a/ebuild-writing/eapi/text.xml
+++ b/ebuild-writing/eapi/text.xml
@@ -624,17 +624,17 @@ src_install() {
</p>
<dl>
<dt><c>source</c></dt>
- <dd><p>
+ <dd>
if building and installing a package
from source,
- </p></dd>
+ </dd>
<dt><c>binary</c></dt>
- <dd><p>
+ <dd>
if installing a binary package,
- </p></dd>
+ </dd>
<dt><c>buildonly</c></dt>
- <dd><p>
+ <dd>
if building a binary package without
installing it.
- </p></dd>
+ </dd>
</dl>
</li>
<li>
diff --git a/general-concepts/tree/text.xml b/general-concepts/tree/text.xml
index 4afd8d5..4d2bf64 100644
--- a/general-concepts/tree/text.xml
+++ b/general-concepts/tree/text.xml
@@ -113,87 +113,70 @@ Software-wise, in general all of the following should be
met in order for a pack
<dl>
<dt>Active, Cooperative Upstream</dt>
<dd>
- <p>
If a package is undeveloped or unmaintained upstream, it can be extremely
difficult to get problems fixed. If a package does not have an active
upstream, the developers who add the package to the tree must ensure that
they are able to fix any issues which may arise.
- </p>
- <p>
+</dd>
+<dd>
Sometimes upstream may have a reason for not wanting their package included
in the tree. This should be respected.
- </p>
</dd>
<dt>Reasonably Stable</dt>
<dd>
- <p>
Keep super-experimental things out of the tree. If you must commit them,
consider using <c>package.mask</c> until things calm down, or better yet make
them available as overlay ebuilds.
- </p>
</dd>
<dt>Reasonably Useful</dt>
<dd>
- <p>
Don't feel obliged to include "Joe's '1337 XMMS Skinz Collection" or "Hans'
Super Cool Fast File System" in the tree just because a few users ask for
it. Stick to things that might actually be of use.
- </p>
</dd>
<dt>Properly Packaged</dt>
<dd>
- <p>
If something is only available in live CVS or dodgy autopackage format,
don't include it until upstream can come up with a decent source package.
Similarly, avoid things that don't have a proper build system (where
relevant) <d/> these are very tricky to maintain.
- </p>
</dd>
<dt>Patching and Distribution Permitted</dt>
<dd>
- <p>
If we can't patch packages as necessary ourselves, we end up relying
entirely upon upstream for support. This can be problematic, especially if
upstream are slow at fixing things. We don't want to be in the situation
where we can't stable a critical package because we're still waiting for a
closed-source vendor to get their act together.
- </p>
-
- <p>
+</dd>
+<dd>
Similarly, not being able to mirror and distribute tarballs ourselves makes
us rely entirely upon upstream mirrors. Experience has shown that these are
often extremely unreliable, with files changing, moving or vanishing at
random.
- </p>
</dd>
<dt>Working Ebuilds</dt>
<dd>
- <p>
If you don't have a <e>working</e> ebuild, don't include it.
- </p>
</dd>
<dt>Portable</dt>
<dd>
- <p>
If software is unportable, it's generally because it's badly written.
Remember that although x86 has a market majority <e>now</e>, it probably
won't in
the not too distant future once x86-64 catches on.
- </p>
</dd>
<dt>Reasonable Security Record</dt>
<dd>
- <p>
Don't include software that has a terrible security record. Each
vulnerability is a <e>lot</e> of work for a lot of people (security teams,
arch
teams and package maintainers).
- </p>
</dd>
</dl>
diff --git a/keywording/text.xml b/keywording/text.xml
index 2149f2d..a1dbed1 100644
--- a/keywording/text.xml
+++ b/keywording/text.xml
@@ -41,41 +41,33 @@ The different levels of keyword are:
<c>arch</c> (<c>x86</c>, <c>ppc-macos</c>)
</dt>
<dd>
- <p>
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.
- </p>
</dd>
<dt>
<c>~arch</c> (<c>~x86</c>, <c>~ppc-macos</c>)
</dt>
<dd>
- <p>
The package version and the ebuild are believed to work and do not have any
known serious bugs, but more testing is required before the package version
is considered suitable for <c>arch</c>.
- </p>
</dd>
<dt>
No keyword
</dt>
<dd>
- <p>
If a package has no keyword for a given arch, it means it is not known
whether the package will work, or that insufficient testing has occurred
for
<c>~arch</c>.
- </p>
</dd>
<dt>
<c>-arch</c> (<c>-x86</c>, <c>-ppc-macos</c>)
</dt>
<dd>
- <p>
The package version will not work on the arch. This could be caused by
badly
written code (for example, non-64-bit or endian clean code), relying upon
particular hardware (for example, a BIOS querying tool would not work on
non-BIOS architectures) or binary only packages.
- </p>
</dd>
</dl>
diff --git a/tools-reference/tr/text.xml b/tools-reference/tr/text.xml
index e7002e1..8a1a236 100644
--- a/tools-reference/tr/text.xml
+++ b/tools-reference/tr/text.xml
@@ -26,27 +26,21 @@ and only writes to standard output. Therefore, you will
have to use
Deleting characters
</dt>
<dd>
- <p>
- To delete all occurrences of certain characters, use <c>tr -d asdf</c>.
- </p>
+ To delete all occurrences of certain characters, use <c>tr -d asdf</c>.
</dd>
<dt>
Deleting repeated characters
</dt>
<dd>
- <p>
- To replace repeated characters with a single character ('squeeze'), use
- <c>tr -s asdf</c>.
- </p>
+ To replace repeated characters with a single character ('squeeze'), use
+ <c>tr -s asdf</c>.
</dd>
<dt>
Transliterating characters
</dt>
<dd>
- <p>
- To replace all 'a' characters with '1', all 'b' with '2' and all 'c' with
- '3', use <c>tr abc 123</c>.
- </p>
+ To replace all 'a' characters with '1', all 'b' with '2' and all 'c' with
+ '3', use <c>tr abc 123</c>.
</dd>
</dl>
