On systems where multiple architectures can be installed (e.g. debian on x64 also can install and run x32) discover has a 50:50 chance of installing the wrong package if a package is both available for both architectures.

The reason for this is that discover never uses the packagekit ARCH filter (PackageKit::Transaction::FilterArch) to limit the selection to the preferred architecture, ultimately resulting in all architectures being returned in arbitrary order (or rather, the API makes no assertions about the order).

This for example results in kipi-plugins on neon installing the i386 package (or trying to) when really it should pick amd64.

When changing the resolve call to
> PackageKit::Transaction * t = PackageKit::Daemon::resolve(names, PackageKit::Transaction::FilterArch);
only native architecture will be tracked. Supposedly this would be unsuitable as well as then one can't install i386 packages (e.g. potential third party binary blob packages that only are available as i386).

The way I understand it this needs a bit of a restructuring WRT how applications are mapped to packages.

a) A Resource could stop holding packageids. Specifically the backend would get all apps from appstream, resolve them via packagekit and note that a given resource is resolved (or not) BUT not keep the packageid in the resource. Since PK can resolve the name we don't need the pkgid and can later simply call install(packagename, filter_ARCH) and if that fails install(packagename, filter_NO_ARCH) as fallback to pick a secondary architecutre package if no primary arch is available.

b) Backend does two resolve queries. One with ARCH and once that is done for all resources that were not resolved it does another resolve run with NO_ARCH. i.e. a Resources has a packagelist that is either from the primary arch or a !primary arch, but not both. Since we map one app to one  packageid for installation this might be the best and most efficient option since we effectively want either-or for installation.

c) A combination of a) and b) might be possible. By default the backend requests two resolves, one with ARCH and one with NO_ARCH. It keeps both sets of information so a discover resource knows which packageids it maps to for the primary architecture as well as !primary. Upon installation request discover could request primary and fall back to !primary if primary installation failed (not sure that is good).

NB: limiting the packageids to ARCH filtered ones may impact update listing as update listing ought to be a complete list of all packages, so only option c) could be a viable option. I am unclear about the implications.

It's also worth noting that if discover has daemon interaction where it throws packagenames (rather than packageids) at the daemon those need to have their need for filtering reviewed as well.

Reproducible: Always