Properly order packages returned by PackageKit so automations executed on 64bit systems won't sometimes pull 32bit packages due to a lack of ordering (Jockey). -- diff -rupN PackageKit-0.6.22.orig/backends/yum/yumFilter.py PackageKit-0.6.22/backends/yum/yumFilter.py --- PackageKit-0.6.22.orig/backends/yum/yumFilter.py 2012-12-19 14:39:41.148069422 -0500 +++ PackageKit-0.6.22/backends/yum/yumFilter.py 2012-12-19 14:56:49.163672753 -0500 @@ -88,6 +88,8 @@ class YumFilter(PackagekitFilter): if (base, version) not in base_list_already_got: output_list.append((pkg, status)) base_list_already_got.append ((base, version)) + output_list.sort() + output_list.reverse() return output_list def _do_newest_filtering(self, pkglist): @@ -116,6 +118,8 @@ class YumFilter(PackagekitFilter): del newest[key] newest[key] = (pkg, state) + newest.values().sort() + newest.values().reverse() return newest.values() def post_process(self): @@ -127,6 +131,8 @@ class YumFilter(PackagekitFilter): if FILTER_NEWEST in self.fltlist: self.package_list = self._do_newest_filtering(self.package_list) + self.package_list.sort() + self.package_list.reverse() return self.package_list def _pkg_compare(self, pkg1, pkg2):
Can you explain what the problem is and what the patch does? Relying on the sort order seems very fragile.
Sure, when on a 64bit system you make a request through PackageKit to install a package where both a 64bit and a 32bit version of the package exist, PackageKit does not order the packages returned. This means that sometimes the first in the list is a 32bit package and the second in the list is 64bit though at other times the reverse is true. Jockey uses pkcon to install kernel modules, however the code always assumes that the first package is the proper package for the architecture in-case multiple matches are returned: pkcon = subprocess.Popen(['pkcon', 'install', '--plain', '-y', package], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE) # we send an "1" to select package if several versions # are available print >>pkcon.stdin, "1\n" Without ordering we found that at times a 32bit package was being listed by PackageKit first, and being installed on a 64bit system causing the process to appear to succeed but since it installed a 32bit kernel module on a 64bit platform it was actually a failure. This corrected the condition so the 64bit package is always listed first.
(In reply to comment #2) > Sure, when on a 64bit system you make a request through PackageKit to > install a package where both a 64bit and a 32bit version of the package > exist, PackageKit does not order the packages returned. There's no ordering enforced by the daemon. > Jockey uses pkcon to install kernel modules, however the code always assumes > that the first package is the proper package for the architecture in-case > multiple matches are returned: That's the wrong way to do it. When you search, just use the "arch" flag to only return results for the native architecture. > pkcon = subprocess.Popen(['pkcon', 'install', '--plain', '-y', > package], > stdin=subprocess.PIPE, stdout=subprocess.PIPE, > stderr=subprocess.PIPE) > > # we send an "1" to select package if several versions > # are available > print >>pkcon.stdin, "1\n" Can't you use the DBus API or libpackagekit? The command line isn't really resigned for this; what if you got asked to agree to a EULA or import a GPG key? Richard.
> There's no ordering enforced by the daemon. Right. > That's the wrong way to do it. When you search, just use the "arch" flag to only return results for the native architecture. When I last attempted to use the arch flag, it didn't seem to work properly but I'll revisit it. > Can't you use the DBus API or libpackagekit? The command line isn't really resigned for this; what if you got asked to agree to a EULA or import a GPG key? Probably so, I'll bring it up with the Jockey devs. This was just a quick fix that doesn't seem to impact the performance or functionality of PackageKit and makes the output cleaner if nothing else when multiple matches are returned.
We moved the upstream bugtracker to GitHub a long time ago. If this issue still affects you please re-create the issue here: https://github.com/hughsie/PackageKit/issues Sorry for the impersonal message, and fingers crossed your issue no longer happens. Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.