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)
New
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.