Bug 61825 - PackageKit ordering patch
Summary: PackageKit ordering patch
Status: RESOLVED NOTABUG
Alias: None
Product: PackageKit
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: Other All
: medium trivial
Assignee: Richard Hughes
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-05 01:47 UTC by Andrew Wyatt
Modified: 2018-08-21 15:52 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Wyatt 2013-03-05 01:47:26 UTC
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):
Comment 1 Richard Hughes 2013-03-05 15:46:41 UTC
Can you explain what the problem is and what the patch does? Relying on the sort order seems very fragile.
Comment 2 Andrew Wyatt 2013-03-05 16:16:32 UTC
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.
Comment 3 Richard Hughes 2013-03-05 16:21:17 UTC
(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.
Comment 4 Andrew Wyatt 2013-03-05 16:37:23 UTC
> 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.
Comment 5 Richard Hughes 2018-08-21 15:52:15 UTC
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.