From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 5F84D1396D9 for ; Mon, 13 Nov 2017 17:35:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E95D0E1260; Mon, 13 Nov 2017 17:35:27 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BEF00E1256 for ; Mon, 13 Nov 2017 17:35:27 +0000 (UTC) Received: from oystercatcher.gentoo.org (oystercatcher.gentoo.org [148.251.78.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id B81F333D3C7 for ; Mon, 13 Nov 2017 17:35:26 +0000 (UTC) Received: from localhost.localdomain (localhost [IPv6:::1]) by oystercatcher.gentoo.org (Postfix) with ESMTP id BB5A89AEB for ; Mon, 13 Nov 2017 17:35:23 +0000 (UTC) From: "Michał Górny" To: gentoo-commits@lists.gentoo.org Content-Transfer-Encoding: 8bit Content-type: text/plain; charset=UTF-8 Reply-To: gentoo-dev@lists.gentoo.org, "Michał Górny" Message-ID: <1510589276.5296812ec1b0d8155480261a49120b2b9347bd0f.mgorny@gentoo> Subject: [gentoo-commits] data/glep:glep-manifest commit in: / X-VCS-Repository: data/glep X-VCS-Files: glep-0065.rst X-VCS-Directories: / X-VCS-Committer: mgorny X-VCS-Committer-Name: Michał Górny X-VCS-Revision: 5296812ec1b0d8155480261a49120b2b9347bd0f X-VCS-Branch: glep-manifest Date: Mon, 13 Nov 2017 17:35:23 +0000 (UTC) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-commits@lists.gentoo.org X-Archives-Salt: 6805029b-189f-4f2c-845b-f5472ebcb21d X-Archives-Hash: 1ec9be6337548f3afff68c94530615c3 Message-ID: <20171113173523.PirJPEJ6XVfUAp5dWYX8n5Uat3MU-dqLolZlk7SiUiA@z> commit: 5296812ec1b0d8155480261a49120b2b9347bd0f Author: Michał Górny gentoo org> AuthorDate: Wed Oct 25 07:18:17 2017 +0000 Commit: Michał Górny gentoo 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.