[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEP-8 pseudo-restriction "hint-dpkg-testsuite-triggers"

Hi Ian,

On 19-06-18 23:23, Ian Jackson wrote:
> Paul Gevers writes ("Re: DEP-8 pseudo-restriction "hint-dpkg-testsuite-triggers""):
>>>> Considering your description above I give you the following alternative
>>>> suggestion: make a gnupg1 specific test, where you install gnupg instead
>>>> of gnupg2 and verify that it works also that way. For a while I was
>>>> testing my package dbconfig-common with both MariaDB and MySQL servers
>>>> (neither of which are my (indirect) dependencies as the server may run
>>>> on a different host).
>>> What, do that and add the gnupg direct dependency to all the other
>>> tests ?
>> No, have just one specific test for gnupg1, and only add it there.
> I think we must be talking at cross purposes.  I'm going to try to
> explain again, to give you another chance to convince me I'm going
> about this the wrong way.  So:
> gnupg2 is the current default in Debian.  dgit is supposed to work
> with both gnupg1 and gnupg2.  It calls gnupg both directly and via
> debsign.  In practice there is no difficulty with gnupg1.  I worry,
> though, about possible regressions in interaction with gnupg2 and
> gpgv.

Ah, I thought you were worried about gnupg1's behavior as gnupg2 is the

> Almost every test makes and verifies signatures, using a stunt set of
> keys.  When testing switched to gnupg2, I discovered (sadly too late
> to make a fuss about it, by the time I had figured out what was going
> on) the gnupg2 startup bugs.  I have been adding increasingly horrific
> workarounds to the test suite.
> I want an early warning if things get worse.  I think the Debian
> gnupg2 maintainers would appreciate that too.  (Upstream's attitude is
> ... more mixed.)  So I need my tests rerun in buster, with gnupg2,
> when gnupg2 is updated.
> Having a test run with gnupg1 might be a bonus but is not really
> important, since gnupg1 works and, realistically, probably isn't going
> to break.

I don't know the design of your tests and I doubt it would matter, but
reading what you said above I would probably force one of all test cases
to use gnupg1 and another one to force gnupg2. That is what we did for
debian-edu. There is a whole (2 or 3 dimensional IIRC) matrix of
combinations that ideally one would test all, but most of the time that
doesn't make sense as that would be a huge waste of the infrastructures
time. So the debian-edu team picked points in the matrix to cover at
least all points on all axes at least once and I believe there are some
additional combinations.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: