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

Bug#987327: Bug#986984: Bug#987327: autopkgtests for debian-edu-doc binary packages


Just to be sure, I love autopkgtest, but I have a few comments.

On 21-04-2021 23:09, Wolfgang Schweer wrote:
> [ Holger Levsen, 2021-04-21 ]
>> we should add autopkgtests to debian-edu-doc to ensure each document 
>> has been built for the three formats pdf, epub and html.

To be honest, I'm wondering if what you're envisioning here shouldn't be
(also) done as BUILD test. I mean, if some documentation goes missing,
it's good to fail the build and prevent a broken package in unstable.
Very often, build tests are used as autopkgtests too, but checking for
existence of files in the binary package only needs to be done once, not
with every dependency change.

> In some cases, verifying the format would have revealed the cause for 
> missing files/internal issues, i.e would have allowed one to locate the 

> broken XML syntax (most cases) more easily.
> src:desktop-base has an autopkgtest to validate XML files, xmllint from 

> libxml2-utils is used. Maybe xmllint could also be used to check HTML 
> files.

That's also a great test during build. Realize however that if you do
this during autopkgtest there's a risk that you'll *block* a new version
of the checker because of a bug in *your* package. Obviously that has to
be weighted against catching bugs in the checker, so it goes both ways,
but *most* of the autopkgtest failures that I've seen that involved
checkers, the checkers actually got better and found an issue in the
reverse dependency. It's obviously a choice you'll have to make and
there's much value in having an autopkgtest, but I just wanted to point
out it's not a free lunch.


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply to: