diff options
| -rw-r--r-- | appendices/common-problems/text.xml | 6 | ||||
| -rw-r--r-- | appendices/contributing/text.xml | 31 | ||||
| -rw-r--r-- | appendices/further-reading/text.xml | 6 | ||||
| -rw-r--r-- | archs/amd64/text.xml | 12 | ||||
| -rw-r--r-- | ebuild-writing/eapi/text.xml | 12 | ||||
| -rw-r--r-- | general-concepts/tree/text.xml | 25 | ||||
| -rw-r--r-- | keywording/text.xml | 8 | ||||
| -rw-r--r-- | 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> |