https://bugs.kde.org/show_bug.cgi?id=369521
Bug ID: 369521
Summary: multiarch not supported (installing wrong package!)
Product: Discover
Version: 5.7.2
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: NOR
Component: PackageKit
Assignee: aleix...@kde.org
Reporter: sit...@kde.org
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
--
You are receiving this mail because:
You are watching all bug changes.
