Bug 839960 - system.listLatestUpgradablePackages suggests not newest only packages
system.listLatestUpgradablePackages suggests not newest only packages
Product: Spacewalk
Classification: Community
Component: API (Show other bugs)
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Tomas Lestach
Red Hat Satellite QA List
Depends On:
Blocks: 854139 space19
  Show dependency treegraph
Reported: 2012-07-13 06:00 EDT by Jan Hutař
Modified: 2014-02-11 12:38 EST (History)
5 users (show)

See Also:
Fixed In Version: spacewalk-java-1.9.2-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 854139 (view as bug list)
Last Closed: 2013-03-06 13:35:27 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 481843 None None None Never

  None (edit)
Description Jan Hutař 2012-07-13 06:00:44 EDT
Description of problem:
API call system.listLatestUpgradablePackages suggests not newest only packages. Both `yum list updates` and WebUI -> system -> Software -> Packages -> Upgrade shows only newest one.

Version-Release number of selected component (if applicable):
SWnightly as of yesterday

How reproducible:

Steps to Reproduce:
1. wget 3 versions of some package, I had:
   drupal7-7.12-1.el5.noarch.rpm  drupal7-7.14-1.el5.noarch.rpm
2. push them to some channel your system is subscribed to
3. Install oldest one (7.12-1.el5 in my case)
4. Confirm that `yum list updates | grep drupal7` and WebUI -> system -> Software -> Packages -> Upgrade only recommends newest (7.14-2.el5)
5. Check API call recommends two:
# python
Python 2.4.3 (#1, Dec 22 2011, 12:12:24) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xmlrpclib, pprint
>>> client = xmlrpclib.Server('https://<fqdn>/rpc/api', verbose=0)
>>> key = client.auth.login('<user>', '<password>')
>>> pprint.pprint(client.system.listLatestUpgradablePackages(key, 1000010366))

Actual results:
[{'arch': 'noarch',
  'from_epoch': ' ',
  'from_release': '1.el5',
  'from_version': '7.12',
  'name': 'drupal7',
  'to_epoch': ' ',
  'to_package_id': 7761,
  'to_release': '2.el5',
  'to_version': '7.14'},
 {'arch': 'noarch',
  'from_epoch': ' ',
  'from_release': '1.el5',
  'from_version': '7.12',
  'name': 'drupal7',
  'to_epoch': ' ',
  'to_package_id': 7760,
  'to_release': '1.el5',
  'to_version': '7.14'}]

Expected results:
[{'arch': 'noarch',
  'from_epoch': ' ',
  'from_release': '1.el5',
  'from_version': '7.12',
  'name': 'drupal7',
  'to_epoch': ' ',
  'to_package_id': 7761,
  'to_release': '2.el5',
  'to_version': '7.14'}]

Additional info:
If this is expected, would it be possible to enhance documentation for the function so it warns about that?
Comment 1 Jan Hutař 2012-07-13 06:02:44 EDT
This was first reported by Prakash Velayutham in the mailing list:

Comment 2 Prakash Velayutham 2012-07-31 06:00:09 EDT
Just wanted to know if there has been any status updates to this bug.

Comment 3 Prakash Velayutham 2012-08-08 10:38:20 EDT

Any updates please?

Comment 4 Tomas Lestach 2012-09-03 08:30:08 EDT
spacewalk.git: 4823565b2e634bc73010d366ff82c432630bca85
Comment 5 Franky Van Liedekerke 2012-09-13 09:13:11 EDT
The same API call also shows packages with the same name from channels the system is not subscribed to. This is the case where people have e.g. redhat and centos packages in spacewalk, both using the same name+version (like the kernel package).
I don't think the system is allowed to install packages from another channel, but it is not very "pretty" ...
Is this also resolved with this new query? If not, I'll to open a new bug report for this.
Also, can this fix be backported somehow to 1.7? Since this caused me quite some troubles when first updating servers (where older kernel packages were installed after newer versions when feeding the resulting list from this API call to system.schedulePackageInstall() )
Comment 6 Franky Van Liedekerke 2012-09-14 11:21:10 EDT
To answer my own question: it still gives package id's from channels the system isn't subscribed to as well.
Comment 7 Jan Pazdziora 2012-10-30 15:23:59 EDT
Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/
Comment 8 Tomas Lestach 2012-10-31 11:56:10 EDT
make the query work on PG ...

spacewalk.git: 594781171402e28f85cdcb9fe7e838e35288a505

Moving back to MODIFIED ...
Comment 9 Tomas Lestach 2012-11-01 08:24:52 EDT
list upgradable packages from server channels only (fix for issue described in Comment#6) ...

spacewalk.git: 1168f61a9d16b42b533a21513c8538529862e745
Comment 10 Lars Delhage 2013-02-22 08:51:55 EST
This problem is also in the API for RHN Satellite 5.5 (and probably earlier then). Should a separate bug be filed for that?
Comment 11 Tomas Lestach 2013-02-25 05:59:21 EST
Yes, current Bug is filed against Spacewalk. If you want to track the issue against any other Product, please, create a separate BZ.
Comment 12 Stephen Herr 2013-03-01 12:07:51 EST
Marking bug as ON_QA since tonight's build of Spacewalk nightly is a release candidate for Spacewalk 1.9.
Comment 13 Stephen Herr 2013-03-06 13:35:27 EST
Spacewalk 1.9 has been released.


Note You need to log in before you can comment on or make changes to this bug.