On 10/17/2017 02:12 PM, Michał Górny wrote:
>
> Abstract
> ========
>
> ...
> The QA checks can inspect the installation image or live system respectively,
Respective to what?
> output and store both user- and machine-oriented QA warning logs, manipulate
> the files and abort the install, as necessary.
>
An oxford comma would make that easier to read: "files, and abort the
install as necessary."
> Motivation
> ==========
>
> ...
>
> 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.
Another weird comma issue, maybe try: "policies, and checks enforcing
correct eclass usage."
> 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``).
>
It's a bit sadistic to have something called a "post-install check" but
then have "postinst check" refer to the other thing.
>
> In case of severe QA issues, the checks are allowed to alter the contents of
> the installation image in order to sanitize them, or call the ``die`` function
> to abort the build.
I'm not sure that having the image silently modified is a good idea. It
seems like everyone would benefit more if the QA check crashed, and let
the maintainer fix his ebuild. Is this already possible with the Portage
checks, or is it new in the repository-based checks?
>
> The post-merge QA checks are executed after the ``pkg_postinst`` ebuild phase
> finishes. They can use the same commands as are permitted in ``pkg_postinst``,
> and access the installed system location ``${ROOT}`` and the temporary
> directory ``${T}``.
>
> The checks are allowed to alter the contents of the filesystem to the same
> degree as ``pkg_postinst`` phase is. They must not call ``die``.
Ditto re: filesystem modification.
>
> Aside to the standard PMS function
>
Aside from
> eqatag
> ~~~~~~
> Synopsis
> ``eqatag [-v] <tag> [<key>=<value>...] [<file>...]``
>
> 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.
If this is used in a post-merge check, isn't it conceivable that you
would want to tag a path outside of $D? For example, if your src_install
creates ${D}/bin/foo and then your pkg_postinst phase gives ownership of
/bin/foo to the "foo" user, I might want to tag /bin/foo (and not
${D}/bin/foo) with a bad-owner tag.
>
> The two types of QA checks were created to account for different kinds
> of common mistakes in ebuilds.
>
> ...
>
> Post-postinst QA checks can be used to verify the state of system after
I think we're calling these "Post-merge" checks.
>
> QA check script format
> ----------------------
>
This is the second appearance of a "QA check script format" section.
>
> Function specification
> ----------------------
Also appears twice.
