This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 839960 - system.listLatestUpgradablePackages suggests not newest only packages
system.listLatestUpgradablePackages suggests not newest only packages
Status: CLOSED CURRENTRELEASE
Product: Spacewalk
Classification: Community
Component: API (Show other bugs)
1.8
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)
Environment:
Last Closed: 2013-03-06 13:35:27 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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
spacewalk-java-1.8.107-1.el5


How reproducible:
always


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
   drupal7-7.14-2.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:

https://www.redhat.com/archives/spacewalk-list/2012-July/msg00029.html
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.

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

Any updates please?

Thanks,
Prakash
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.

https://fedorahosted.org/spacewalk/wiki/ReleaseNotes19

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