Michał Górny wrote:
> ( 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 betwe
Dnia 2014-09-13, o godz. 16:03:31
Jauhien Piatlicki napisał(a):
> Hi,
>
> 11.09.14 00:20, Michał Górny написав(ла):
> >
> > 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 pac
Hi,
11.09.14 00:20, Michał Górny написав(ла):
>
> 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 sy
Dnia 2014-09-11, o godz. 00:20:21
Michał Górny napisał(a):
> 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 s
On 9/11/14 12:20 AM, Michał Górny wrote:
> 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
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 e
