ci.debian.org and pkg-perl packages

[Martin Pitt]

Hello all,

Niko Tyni [2014-09-10 19:58 +0300]:
> So moving it to build-deps would take much of the point away.

Ah thanks for the explanation.

> Thanks for the "needs-recommends" hint, I had missed that. I expect
> it would fix most of the problems, and we could still auto-skip packages
> with Suggestions if there too many of them to handle individually.

I'm happy to add "needs-recommends" to the dynamic template if you as
the Perl maintainers say that this is the right thing to do (it's
certainly plausible to me).

My gut feeling is that a module which the package is trying to import,
but is only a Suggests: is more likely to be a packaging bug (and thus
an "honest" and useful test failure) than not?

> It would need a new section in the test control file, something like
> 
>     Test-Command: /usr/share/pkg-perl-autopkgtest/runner with-recommends
>     Depends: @, pkg-perl-autopkgtest
>     Restrictions: needs-recommends
> 
> and updating pkg-perl-autopkgtest accordingly.

What would need changing in pkg-perl-autopkgtest? Or do you mean
https://anonscm.debian.org/cgit/pkg-perl/packages/pkg-perl-tools.git/commit/?id=444745528c ?
(FWIW, that smells a bit too much like black magic to me, but we are
still in the early tuning steps after all)

> This brings me to a more generic question: should we treat these
> synthesized test control files in autopkgtest as a temporary
> solution while individual packages grow control files of their own, 
> or is this a sustainable solution of centralizing the test logic?

Admittedly these dynamically generated control files are a bit against
the spirit of DEP-8 to have an explicit test control. However, I think
it's not too bad as the benefit of not having to change 3.000 source
packages all the time is just immense. The one thing I'd like to add
to the source packages is an "XS-Testsuite: autopkgtest" field though,
so that we can stop maintaining hardcoded whitelists at some point
(but from my POV it's ok if that takes several years even).

> I'm asking because while we designed our generic test control files as
> extensible as possible without modification, we didn't envision needing
> this "needs-recommends" thing. There are probably only a few dozen copies
> of the control file uploaded at this point, so updating them is still
> easy. But the next necessary modification might need two hundred or two
> thousand uploads to get all the packages converted.

Right, and it might just be easier and preferable to drop the explicit
control files? Anyway, if the packages that already have it succeed
their tests, there is no reason to add the restriction.

> Any hope of a fix for #759753 (include directive in test control
> files)?  That would solve the problem quite neatly IMO. Even if it
> isn't implemented right away, just knowing it's not a 'wontfix' bug
> would help. In that case I guess we could wait for it and rely on the
> synthesized control files in the meantime (and stop uploading copies of
> the current version of the generic debian/tests/control.)

I haven't yet responded because I'm still trying to find some quiet
time to think about this thoroughly. My first instinct is that in the
currently proposed form it's not very helpful -- it combines the
disadvantage of having to do boilerplate source changes with the
disadvantage of still not having a self-contained test description
(i. e. a fully working explicit control file).
A file which is essentially just "#include perl-test.control" doesn't
say much beyond the already obvious fact that this is a Perl package.
But as I said, I don't think this should be designed in a hurry.

So I don't consider it an outright "wontfix", but I'd like to discuss
it in more depth first (and probably in a separate thread).

But I understand that with the current fully dynamic method this isn't
very urgent, or am I missing something?

Thanks,

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)