virtual-packages do not pick a seeded package (ordering dependent)

Bug #1895011 reported by Christian Ehrhardt 
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
germinate (Ubuntu)
Undecided
Unassigned

Bug Description

Hi,
I've started to look into what we considered a false positive in component mismatches

o esmtp: esmtp-run
 [Reverse-Depends: logcheck (MAIN)]

The logcheck package has:
Depends: ... default-mta | mail-transport-agent ...

default-mta as well as mail-transport-agent are purely virtual

Postfix is in main and would provide both
Package: postfix
...
Provides: default-mta, mail-transport-agent

But postfix does not exist on i386.

Due to that when germinating all arches i386 will do this:
But from the log of germinate:
 26 ? Unknown dependency default-mta by logcheck
 27 * Chose esmtp-run out of mail-transport-agent to satisfy logcheck
 28 ? Unknown dependency esmtp by esmtp-run
 29 * Chose mail-transport-agent to satisfy logcheck

But while the non-existance of postfix@i386 is the reason it can't find default-mta
it is unclear why it picks esmtp-run for mail-transport-agent as there would be lsb-invalid-mta that is in main even on i386.

This can be reproduced with the simpler seeds I created:
https://code.launchpad.net/~paelzer/ubuntu-seeds/+git/ubuntu/+ref/debug-esmtp-listing
https://code.launchpad.net/~paelzer/ubuntu-seeds/+git/platform/+ref/debug-esmtp-listing

Those only seed logcheck and we can see the issue.

I'd have expected that ordering isn't important, but I've found that ensuring to have lsb-invalid-mta show up before logcheck will avoid the issue.

Not sure how to proceed (see also the IRC discussion we had today) is this a bug that could be improved in germinate or am I looking the wrong way with this.

Related branches

summary: - virtual-packages do not pick a seeded package
+ virtual-packages do not pick a seeded package (ordering dependent)
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

We landed our "avoidance" branch to relieve the immediate issue that we had, but understanding and/or fixing what happens underneath in the long run would be awesome.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

The avoidance only helped a short bit, it really seems to have some randomness left.
Currently it shows up again in component mismatches.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers