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

[Holger Levsen]

Hi Johannes, 

sorry for the delay…!

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…?!
 
> 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.

oh, wow.

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

ic

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

so should "sid" still be part of the job name (because dose3+apt+dpkg
from sid are used) or should that be omitted?
 
> > > 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. ;)

:) we can improve it incrementally…

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

the stuff quoted above seems nice to me…!

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

In any case we should get this merged and deployed soon…! ;)


-- 
cheers,
	Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/qa-jenkins-dev/attachments/20160903/ff7b3cc0/attachment.sig>