diff options
Diffstat (limited to 'keywording')
| -rw-r--r-- | keywording/text.xml | 71 |
1 files 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. |