[gentoo-dev] Early idea: install_qa_check() refactor and 'public API'

[Michał Górny]

Hello, everyone.

Portage has currently two major QA mechanisms: repoman
and install_qa_check(). While we would love to put all the QA
in repoman and make it the ultimate tool preventing bad commits, it is
very limited in power. Most importantly, it can't really access
the build environment of an ebuild or the files installed by it. That's
why install_qa_check() is very important.

At the moment, install_qa_check() is one huge function that is run
after src_install(). It does all the QA checks but also stripping,
document compression and a few other random tasks since 'that was
a convenient place to put them'. Since it is not really convenient to
have all the QA checks randomly placed in one function, I've recently
started refactoring that code. I would like to share my vision with you
and get your feedback.


I would like the post-install QA checks to be modularized, standardized
and extensible. For a start, I've split most of the function into
install-qa-check.d/ scripts in Portage and made install_qa_check()
function run them [1]. However, that's just a start.

I would like to have install-qa-check.d in three main places:

1. /usr/lib/portage/install-qa-check.d (or alike) for scripts
installed by Portage and other packages,

2. /etc/portage/install-qa-check.d for extra scripts installed
by sysadmin,

3. ${repo}/metadata/install-qa-check.d for repository-specific
QA checks.

The rationale for (3) is quite simple: many of the modern QA checks are
results of policies specific to Gentoo tree and the eclasses in it --
like my recent bash-completion checks (still in review queue). Keeping
them in Portage is cumbersome, and has some code duplication factor.

For this to work, the whole scheme needs to be standardized properly.
I think that the following rules could do the job well:

1. QA check scripts are run after src_install() but before any other
post-install procedures such as stripping and compression. Checks have
full access to the ebuild environment equivalent to src_install().

2. Checks are sourced in a subshell. This means that they can randomly
play with environment, working directory and bash options without
bothering to restore them.

2a. That is, the snippet used to run them looks like:

  ( source "${f}" || die "sourcing ${f} failed" )

2b. Unless someone knows a way around this, this means that the check
-- unless 'die'-fatal -- needs to ensure non-zero status of last
comment, likely via some trailing 'true' or ':'. Since we can't
distinguish between non-zero return from script and non-zero exit due to
syntax error or so.

3. Checks can be non-fatal (output warnings) or fatal (die). Checks can
also automatically fix some issues while outputting a warning (like we
strip unsafe RPATHs right now or remove executable bits from static
libs).

3a. Do we want to legalize eqawarn at some point? Or just use ewarn
here?

3b. We really do want to legalize die in subshells. We can't live
without it anyway, so why pretending it's illegal?

4. Checks can inherit eclasses. This goes opposite the generic rule
but allows us to save some code duplication. For example, we can get
paths from eclasses instead of reinventing them. It's also relatively
safe since we're in a subshell.

4a. But you need to be careful not to break the working tree, or fail
due to EAPI unsupported by eclass or something like that :).


What do you think? Did I miss something? Do you have any ideas how to
improve this?


[1]:https://github.com/mgorny/portage/commit/install-qa-check-refactor

-- 
Best regards,
Michał Górny