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