Bug 500505 - Return type mismatch for packages.findByNvrea
Summary: Return type mismatch for packages.findByNvrea
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: API
Version: 530
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Brad Buckingham
QA Contact: Sayli Karmarkar
URL:
Whiteboard:
Depends On:
Blocks: 456996
TreeView+ depends on / blocked
 
Reported: 2009-05-12 22:47 UTC by Sayli Karmarkar
Modified: 2009-09-10 19:55 UTC (History)
2 users (show)

Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-10 19:55:38 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Sayli Karmarkar 2009-05-12 22:47:52 UTC
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 14:01:03 UTC
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 15:36:10 UTC
(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 15:57:45 UTC
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 16:19:53 UTC
master git commit: c1b011443463f9ae3f4f9a2ce386005b1b49f27e
vader git commit: 34bbc2fb586e92a87effb661ce47a0881cd501f1

Comment 6 Sayli Karmarkar 2009-06-12 18:04:03 UTC
verified.

Comment 7 Steve Salevan 2009-08-26 19:14:27 UTC
RELEASE_PENDING from latest Stage build...  docs appropriately updated to reflect list instead of struct.

Comment 8 Brandon Perkins 2009-09-10 19:55:38 UTC
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.