[Qa-jenkins-dev] dpkg, apt and dose3 do not agree in many synthetic dependency situations involving multiarch

[Johannes Schauer]

Hi Holger,

Quoting Holger Levsen (2016-08-19 12:04:17)
> I agree the name is bad, because deb-m-a-dep-check doesn't explain anything
> and doesn't hint at what you have described in the first paragraph above.
> 
> So I would like dpkg+apt+dos3+depends-consens better as a job name, for
> example.

Good idea! Lets name it dpkg_apt_dose3_solvers_agree then.

> And then I wonder, for which package(s) this job does this or these tests?
> for all?

No, it runs this for 8624 synthetically created dependency situations.

> Then the job name should probably be dpkg+apt+dos3+depends-consens-sid or
> such. Ah, you have that ;)

I named it *_sid because the job is run *on* sid not because the job tests
packages *from* sid.

> Also, please reflect what the job does in description: 'Build the master
> branch of https://gitlab.mister-muffin.de/josch/deb-m-a-dep-check'

Okay, I will write:

| Checks if dose3, apt and dpkg agree on how to resolve the relationships
| between two packages.

> Last and probably *not* least, I dislike that the actual test code is living
> on another server, I would much prefer to run code from stable or at least
> sid or from jenkins.d.n.git - but then we have other jobs like this already…

I do not mind to put my code elsewhere. What do you mean by running the code
from stable or sid? To upload the testing code as a package to Debian main? I'm
afraid that the code will not be useful besides for this jenkins job. Which
location of the git repository would be most comfortable for you?

> Do you plan to upload deb-m-a-dep-check to sid anytime soon? (Or why is it a
> Debian package? (Which I conclude from the shell command to be run, I havent
> actually looked at the git repo ;)

It is a Debian package because I was told that this allows to easily set up the
dependencies that my job needs in the chroot. This way, the requirements for
the job are self-contained inside the git repository in a machine readable way
and do not live elsewhere. Another advantage is, that users who want to try it
out themselves, do not have to install the dependencies on their machines
manually but can just run sbuild or pbuilder which will then install the
dependencies inside the chroot for them and run the script as part of the
"build process".

> > > Running it takes about 40 minutes and currently requires that you are on
> > > amd64
> 
> is it single-threaded or will it benefit from multiple cores?

It can be made to run in parallel very easily via xargs. If running it on X
cores instead is a better choice for jenkins than having long runtimes on a
single core, then I can add this. I just naively thought that jenkins would
prefer to have long running jobs that does not stress many cores much at the
same time.

> > > Here are some more statistics of the results:
> > > 
> > > Dpkg and apt agree but dose3 does not: 18.1%
> > > Dpkg and dose3 agree but apt does not: 4.7%
> > > Apt and dose3 agree but dpkg does not: 20.7%
> 
> does that mean, for <60% apt+dpkg+dose3 agree? :-)

No, this number improved considerably and now they agree in 72% of the test
cases.

> > +    name: 'deb-m-a-dep-check_sid'
> 
> I think there should be a job run for stretch too, with the same frequency
> and probably a monthly run job for jessie as well.

As no packages from Debian main are tested, a job run on sid is sufficient.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/qa-jenkins-dev/attachments/20160819/7b93ac7d/attachment.sig>