Re: [gentoo-dev] [RFC] GLEP 65 v2: Post-install QA checks (now with post-merge checks)

[Michał Górny]

W dniu wto, 24.10.2017 o godzinie 17∶57 -0400, użytkownik Michael
Orlitzky napisał:
> 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?

To the type of check, as explained later? If you want to help, then
please be specific instead of asking questions and expecting me to
figure out how should I change it.

> > 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."

Wouldn't that change the meaning? The point is it can do all those
things as necessary, not just the last.

>
>
> > 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."

Done.

> > 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.

Switched to using only post-merge.

> > 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?

I'm pretty sure this was used somewhere in Portage internally. Anyway,
if you want to change it, then convince people it's fine to add a new
check that is going to cause random packages to suddenly explode for
stable users when the problem can be fixed trivially.

> > 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.

This is technically needed for the checks to work. If you don't update
outdated caches, then every single next postinst check will trigger.
>
> > Aside to the standard PMS function
> >
>
> Aside from

Fixed.

> > 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.

It's a wording issue. The point is, path is the same as you would pass
to do* etc. Fixed.

> > QA check script format
> > ----------------------
> >
>
> This is the second appearance of a "QA check script format" section.
>
>
> >
> > Function specification
> > ----------------------
>
>
> Also appears twice.

How is that a problem? It appears twice because it strictly corresponds
to the same section in specification.

-- 
Best regards,
Michał Górny