Resolution of virtual package dependencies is not deterministic

[bahendri]

Identical calls to aptly snapshot pull can return different sets of packages. I've narrowed down the inconsistency to the resolution of virtual package dependencies. Aptly does not always choose the same virtual package.

Detailed Description

As a small example, consider the Xenial package system-config-printer-gnome which depends on the virtual package packagekit-system-interface. The virtual package can be provided by either packagekit or python3-aptdaemon.pkcompat.

$ aptly snapshot create empty empty
$ aptly repo create test
$ mkdir downloads && cd downloads && apt download python3-aptdaemon.pkcompat packagekit system-config-printer-gnome
$ aptly repo add test *.deb
$ aptly snapshot create test-snapshot from repo test
$ echo "{}" > default.conf
$ for i in {1..30}; do aptly -config default.conf snapshot -architectures=amd64 -dry-run pull empty test-snapshot dest-snapshot 'system-config-printer-gnome'; done | grep "[+]" | sort | uniq -c
      7 [+] packagekit_0.8.17-4ubuntu6~gcc5.4ubuntu1.3_amd64 added
     23 [+] python3-aptdaemon.pkcompat_1.1.1+bzr982-0ubuntu14_all added
     30 [+] system-config-printer-gnome_1.5.7+20160212-0ubuntu2_all added

As can be seen, 30 identical calls to aptly snapshot pull resulted in two different results. 23 times, aptly pulled in one package, and 7 times, it pulled another.

Context

Self-consistency within aptly is useful since it makes it easier to determine whether differences between two snapshots are meaningful (something is different about the underlying inputs) versus incidental (one optional dependency was chosen over another).

Can be resolved by ensuring consistent ordering when building the providesIndex in deb/list.go.

Your Environment

aptly version 1.2.0-3 (ported from Bionic)

$ lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.5 LTS
Release:        16.04
Codename:       xenial

[smira]

yep, I agree that it should be deterministic whenever aptly has a choice.

I'm not sure -dep-follow-all-variants would resolve the issue at the price of pulling more deps.

One nice feature might be to pick provides which builds up less dependencies