Bug 500505 - Return type mismatch for packages.findByNvrea
Return type mismatch for packages.findByNvrea
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: API (Show other bugs)
530
All Linux
low Severity medium
: ---
: ---
Assigned To: Brad Buckingham
Sayli Karmarkar
:
Depends On:
Blocks: 456996
  Show dependency treegraph
 
Reported: 2009-05-12 18:47 EDT by Sayli Karmarkar
Modified: 2009-09-10 15:55 EDT (History)
2 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-10 15:55:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sayli Karmarkar 2009-05-12 18:47:52 EDT
Description of problem:
packages.findByNvrea is returning list of packages but the docs say it returns one package (struct and not List of structs).
Comment 1 Clifford Perry 2009-05-13 10:01:03 EDT
Sounds like a possible bug. Can you give a specific example of input you did for the call and then the output. A package Name-Version-Release-Epoch-Arch *should* be unique for Satellite, unless you flip the 'enable_nvrea=0' within rhn.conf to 1 (which is default in Spacewalk). 

So, for Spacewalk - this API returning multiple packages sounds correct, in Satellite it should be a single package by default. 

Either way - I agree with bug report, sounds like that the API call is doing the right thing, we just need to update the doc associated with the call. 

Cliff
Comment 3 Sayli Karmarkar 2009-05-13 11:36:10 EDT
(In reply to comment #1)
> Sounds like a possible bug. Can you give a specific example of input you did
> for the call and then the output. 

>>> server.packages.findByNvrea(key, "zip", "2.31", "1.2.2", "", "i386")

[{'arch_label': 'i386', 'epoch': '', 'version': '2.31', 'last_modified': <DateTime u'20070308T00:00:00' at -48359294>, 'provider': 'Unknown', 'release': '1.2.2', 'path': 'redhat/NULL/640/zip/2.31-1.2.2/i386/640d994ad438d014e828c07c4426d138/zip-2.31-1.2.2.i386.rpm', 'id': 584, 'name': 'zip'}]

So, basically for satellite it IS returning unique package but as a list of one package instead of struct of details of that unique package.  

> A package Name-Version-Release-Epoch-Arch
> *should* be unique for Satellite, unless you flip the 'enable_nvrea=0' within
> rhn.conf to 1 (which is default in Spacewalk). 
> 
> So, for Spacewalk - this API returning multiple packages sounds correct, in
> Satellite it should be a single package by default. 
> 
> Either way - I agree with bug report, sounds like that the API call is doing
> the right thing, we just need to update the doc associated with the call. 
> 
> Cliff  


Yup. If api is doing the right thing of returning list of one package, then return values in the doc should be updated. Also description of the api should be changed from "Lookup the details for the package with the given name, version, release, architecture label, and (optionally) epoch" to something like "List the details for packages with given name, version, release, architecture label, and (optionally) epoch". 

~SayliK
Comment 4 Brad Buckingham 2009-05-13 11:57:45 EDT
The return should be a list, so an update to the doc is necessary.  Possibly someone updated the API to handle the Spacewalk case, but forgot to update the docs.
Comment 5 Brad Buckingham 2009-06-05 12:19:53 EDT
master git commit: c1b011443463f9ae3f4f9a2ce386005b1b49f27e
vader git commit: 34bbc2fb586e92a87effb661ce47a0881cd501f1
Comment 6 Sayli Karmarkar 2009-06-12 14:04:03 EDT
verified.
Comment 7 Steve Salevan 2009-08-26 15:14:27 EDT
RELEASE_PENDING from latest Stage build...  docs appropriately updated to reflect list instead of struct.
Comment 8 Brandon Perkins 2009-09-10 15:55:38 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1434.html

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