ci.debian.org and pkg-perl packages

Niko Tyni ntyni at debian.org
Wed Sep 10 16:58:48 UTC 2014


On Wed, Sep 10, 2014 at 04:30:51PM +0200, Martin Pitt wrote:
> > > (3) Another failure type seems to be packages with "missing" build
> > > dependencies, like
> > > https://people.debian.org/~mpitt/tmp/perl-failures/alice/log

> > We could skip the syntax.t check if there are Recommendations or
> > Suggestions in debian/control. The alternative is to maintain
> > a list of modules that we don't want to check, and that smells
> > a bit too much like busywork.
> 
> I don't understand that fully, but I want to point out that we have
> the "needs-recommends" restriction in autopkgtest which will cause
> the test dependencies' recommends to be installed. Would that help?
> 
> Alternatively, could the syntax check be done in the build-deps check
> instead of the runtime-deps check?

Despite the name, the main use of syntax.t is probably to catch missing
runtime dependencies in all modules shipped in the package.  (The use.t
test only exercises the "main" module.)

It also catches an occasional module with syntax error but I expect such
problems to be much less infrequent.

So moving it to build-deps would take much of the point away.

The problem with packages that have Recommendations or Suggestions is
that typically such a package contains some modules that need those and
fail syntax.t when they aren't installed. And we don't want to maintain
a list of modules with expected failures.

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.

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.

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?

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.

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.)

> Together with your couple of other proposals I think we have enough
> fixes to re-run the ~ 370 failures once they are in
> pkg-perl-autopkgtest (and of course the fixes which were committed
> recently to autopkgtest itself). Let me know when you'd like this to
> get done.

Nice, thanks. I guess we should decide what we do on this recommends
thing first.
-- 
Niko Tyni   ntyni at debian.org



More information about the autopkgtest-devel mailing list