Bug 839960 - system.listLatestUpgradablePackages suggests not newest only packages
Summary: system.listLatestUpgradablePackages suggests not newest only packages
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: API
Version: 1.8
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Tomas Lestach
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: 854139 space19
TreeView+ depends on / blocked
 
Reported: 2012-07-13 10:00 UTC by Jan Hutař
Modified: 2014-02-11 17:38 UTC (History)
5 users (show)

Fixed In Version: spacewalk-java-1.9.2-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 854139 (view as bug list)
Environment:
Last Closed: 2013-03-06 18:35:27 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 481843 0 None None None Never

Description Jan Hutař 2012-07-13 10:00:44 UTC
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 10:02:44 UTC
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 10:00:09 UTC
Just wanted to know if there has been any status updates to this bug.

Thanks,
Prakash

Comment 3 Prakash Velayutham 2012-08-08 14:38:20 UTC
Hello,

Any updates please?

Thanks,
Prakash

Comment 4 Tomas Lestach 2012-09-03 12:30:08 UTC
spacewalk.git: 4823565b2e634bc73010d366ff82c432630bca85

Comment 5 Franky Van Liedekerke 2012-09-13 13:13:11 UTC
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 15:21:10 UTC
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 19:23:59 UTC
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 15:56:10 UTC
make the query work on PG ...

spacewalk.git: 594781171402e28f85cdcb9fe7e838e35288a505


Moving back to MODIFIED ...

Comment 9 Tomas Lestach 2012-11-01 12:24:52 UTC
list upgradable packages from server channels only (fix for issue described in Comment#6) ...

spacewalk.git: 1168f61a9d16b42b533a21513c8538529862e745

Comment 10 Lars Delhage 2013-02-22 13:51:55 UTC
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 10:59:21 UTC
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 17:07:51 UTC
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 18:35:27 UTC
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.