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

[Johannes Schauer]

Hi,

Quoting Holger Levsen (2016-09-03 17:19:27)
> On Wed, Aug 24, 2016 at 06:03:25PM +0200, Johannes Schauer wrote:
> > Quoting Holger Levsen (2016-08-24 17:23:12)
> > > why those 8624 situations? how where they chosen or created?
> > 
> > binary packages and source packages can use several properties to declare how
> > they related to each other. These are:
> > 
> >  - Multi-Arch values (no, foreign, same, allowed)
> >  - Relationship types (depends, conflicts, build-depends, build-conflicts)
> >  - Package type (binary, source)
> >  - Provides (nothing, normal, architecture qualified)
> >  - Package Architecture (native, foreign)
> >  - Dependency relationship (normal, architecture qualified, :any, :native)
> > 
> > If you now create all combinations of above properties between two packages and
> > remove the invalid cases (for example only source packages have build-depends
> > and build-conflicts) then you end up with 8624 different ways that two packages
> > can relate to each other.
> 
> Ah, wow. Maybe put the above in the job description, for the next person
> who'll be wondering…?!

done.

> so should "sid" still be part of the job name (because dose3+apt+dpkg from
> sid are used) or should that be omitted?

It should probably be omitted. Also done.

> > > > 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?
> > > 
> > > I'd prefer to have it in jenkins.d.n.git but I see how this ain't
> > > useful…
> > 
> > Why would it not be useful? It could certainly be done.
> > 
> > Should I rewrite the script as a patch of the jenkins.d.n.git?
> 
> if thats feasable, yes, please.

I now wrote a patch against jenkins that integrates the script. See commit
a6daf12dfe760e1883a266093c38f99482aa77ee on
http://gitlab.mister-muffin.de/josch/jenkins.debian.net.git

It splits the script into two parts:

bin/dependency_solvers_agree.sh is doing the actual work but is not specific to
jenkins and can also be used outside of it.

bin/dependency_solvers_agree_parallel.sh is jenkins specific and calls
bin/dependency_solvers_agree.sh in parallel using xargs and also prints some
additional summaries.

A remaining problem is, how to run this script inside a sid chroot. Because as
far as I understand, the chroot started by bin/chroot-run.sh does not have
access to the scripts in /srv/jenkins/bin. Since the job only requires the two
shell scripts above, maybe those can be copied into the chroot somehow? Or
maybe /srv/jenkins/bin could be bind-mounted read-only into the chroot? What is
the best way to solve this problem?

Thanks!

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