[gentoo-commits] data/glep:glep-manifest commit in: /

[Michał Górny]

commit:     5296812ec1b0d8155480261a49120b2b9347bd0f
Author:     Michał Górny <mgorny <AT> gentoo <DOT> org>
AuthorDate: Wed Oct 25 07:18:17 2017 +0000
Commit:     Michał Górny <mgorny <AT> gentoo <DOT> org>
CommitDate: Mon Nov 13 16:07:56 2017 +0000
URL:        https://gitweb.gentoo.org/data/glep.git/commit/?id=5296812e

glep-0065: Apply suggestions from Michael Orlitzky

 glep-0065.rst | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/glep-0065.rst b/glep-0065.rst
index a8a7321..af641d7 100644
--- a/glep-0065.rst
+++ b/glep-0065.rst
@@ -18,9 +18,9 @@ This GLEP provides two kinds of QA check: checks run on the installation image
 once ``src_install`` returns, and checks run on the live system once
 ``pkg_postinst`` returns. The checks can be provided by the Package Manager,
 repositories, packages (installed system-wide) and the system administrator.
-The QA checks can inspect the installation image or live system respectively,
-output and store both user- and machine-oriented QA warning logs, manipulate
-the files and abort the install, as necessary.
+The QA checks can inspect the installation image or live system, output
+and store both user- and machine-oriented QA warning logs, manipulate files
+and abort the install.
 
 
 Motivation
@@ -34,8 +34,9 @@ the installed files. This is where post-install QA checks become useful.
 
 Over time, many different QA checks have been added to Portage. That includes
 checks corresponding to generic Gentoo rules (like filesystem hierarchy,
-security requirements), checks enforcing Gentoo team policies and correct
-eclass uses. Some of the checks depend on external tools being present.
+security requirements), checks enforcing Gentoo team policies, and checks
+enforcing correct eclass usage. Some of the checks depend on external tools
+being present.
 
 Keeping those checks directly in Portage sources has two major disadvantages:
 
@@ -58,7 +59,7 @@ There are two kinds of QA checks defined in this specification:
 
 1. Post-install QA checks (``install-qa-check.d``),
 
-2. Post-merge (postinst) QA checks (``postinst-qa-check.d``).
+2. Post-merge QA checks (``postinst-qa-check.d``).
 
 The post-install QA checks are are executed after the ``src_install`` ebuild
 phase finishes but before the binary package is built or the ``pkg_preinst``
@@ -117,7 +118,7 @@ run in an isolated subshell, and therefore can safely alter the environment
 and change the working directory. QA scripts must always end with a command
 terminating with a successful exit code.
 
-Aside to the standard PMS functions, two additional commands are provided:
+Aside from the standard PMS functions, two additional commands are provided:
 
 1. ``eqawarn`` to output QA warnings to user,
 2. ``eqatag`` to store machine-readable information about QA issues.
@@ -150,8 +151,8 @@ Synopsis
 Tag the package with specific QA issues. The *tag* parameter is
 a well-defined name identifying specific QA issue. The tag can be additionally
 associated with some data in key-value form and/or one or more *files*.
-The file paths are relative to installation image (``${D}``), and need to
-start with a leading slash.
+The file paths are relative to the installation root (``${D}`` in post-install
+checks or ``${ROOT}`` in post-merge), and need to start with a leading slash.
 
 If ``-v`` (verbose) parameter is passed, the function will also output
 newline-delimited list of files using ``eqawarn``. This is intended
@@ -181,7 +182,7 @@ account for various problems caused by the ebuild code up to and including
 ``src_install``, the upstream code executed as part of any of those phases
 and the supplied files.
 
-Post-postinst QA checks can be used to verify the state of system after
+Post-merge QA checks can be used to verify the state of system after
 the package is merged and its ``pkg_postinst`` phase is executed. They mostly
 aim to detect missing postinst actions but can do other live system integrity
 checks.