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

Obviously, one can create even more test cases by also adding package versions
to the mix and then also test crazy stuff like versioned provides. I limited it
to cross architecture test cases because the multiarch documentation actually
doesn't explain much if one looks more closely. So for example for the 28% of
testcases that dose3/apt/dpkg do not agree, it is actually not obvious who is
wrong or what the best fix would be.

So this jenkins test is for solver developers to check where their solvers can
be improved, where they have to talk with others to find a good solution as
well as for documentation writers to at some point write down how multiarch
*really* works. The perfect documentation would be able to explain how *all*
the test cases should be resolved correctly. We don't have that right now.

> > I named it *_sid because the job is run *on* sid not because the job tests
> > packages *from* sid.
> 
> those "dependency situations" are not taken from sid?

Correct.

> > Okay, I will write:
> > 
> > | Checks if dose3, apt and dpkg agree on how to resolve the relationships
> > | between two packages.
> 
> hm. see my questions above ;)

You know from past conversations, that I'm notoriously bad with describing
stuff in a short, concise and understandable manner. ;)

If you know a way of how to formulate my explanation above in a better way, I
am all ears.

> > 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?

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/20160824/b148a5ab/attachment.sig>