On 18/05/16 01:14, Kent Fredric wrote:
> On 18 May 2016 at 04:05, Sébastien Fabbro <bicatali@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 )
>
Yes, whilst that's a special case, it would be desirable to collaborate
with another maintainer/team/project to devise a test schedule that was
independent from the target language, if possible. But there will always
be exceptions and issues and such with these things .. :/