On 18 May 2016 at 04:05, Sébastien Fabbro <bicat...@gentoo.org> wrote: > Basically CI for ebuilds: it could be implemented as a script living > in the package directory, something like a .travis.yml in the GitHub > repositories or may be an EAPI change. Debian has a similar project > [1]. Upstream could provide CI tests and sometimes they do, but we > want to make sure the package integrates well in an installed Gentoo > distribution.
Something like $CAT/$PN/maintainers/tests/<*> or something like that I could live with, the idea being to keep as much of this content *out* of the main ebuild flow as possible. I'd much rather however not to require files in $CAT/$PN to be changed, but to have a schema for code that can be run conditionally on any suitable package via matching ( CAT, PN, inherit, project=, maintainer= ) properties. Mostly, because there are a lot of places where you'd never want to implement the logic for a single package, you'd want to employ it for a whole bunch. Unfortunately, at present, the *sorts* of logic I personally see myself implementing would require additional dependencies to perform. This is why we're not already doing it in src_test(), because it would expand the dependency graph for end users without benefit, ( and in the way I'm thinking, results in risking a circular dependency, as some of the tests I'm wanting to do would require Perl modules installed, but these tests are to check things about Perl modules, which risks requiring itself to validate itself ...., and exposing users to that is inexcusable ) -- Kent KENTNL - https://metacpan.org/author/KENTNL
