Bug 118778 - RFE raise KeyError rather than returning "(none)" for header sequence methods
Summary: RFE raise KeyError rather than returning "(none)" for header sequence methods
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rpm
Version: 3.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-03-20 03:48 UTC by Bob Drzyzgula
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-03-20 15:47:14 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Python script which exhibits the problem (900 bytes, text/plain)
2004-03-20 03:55 UTC, Bob Drzyzgula
no flags Details
output of the test.py script on a Fedora Core 1 machine (514 bytes, text/plain)
2004-03-20 04:00 UTC, Bob Drzyzgula
no flags Details

Description Bob Drzyzgula 2004-03-20 03:48:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6)
Gecko/20040113

Description of problem:
Somehow several rpms (over 190 on my RHEL 3.0 WS system), including
ones that don't have triggers, are getting a TRIGGERTYPE tag that is
set to a null or None value.

Note that is the problem that has been discussed on rpm-list
under the thread "Python API: TRIGGERTYPE unsupported type".

Version-Release number of selected component (if applicable): 
4.2.1-4.4

How reproducible:
Always

Steps to Reproduce:
1. Install RHEL 3.0 (or RH9 or FC1)
2. run

#!/usr/bin/python
import rpm,sys
tn = rpm.tagnames
ts = rpm.TransactionSet()
mi = ts.dbMatch('name', 'termcap')
h = mi.next()
print h['TRIGGERTYPE']

Actual Results:  Terminates with a TypeError exception


Expected Results:  It should print a value for TRIGGERTYPE. If the
header didn't have a TRIGGERTYPE tag, it should terminate with a
KeyError exception.

Additional info:

I will attach a longer Python script, "test.py" and it's output,
which should do a bit better job of showing the problem. The output
is from a Fedora Core 1 machine (all I have available at this writing) 
but it works the same way on a RHEL 3.0 machine.

Comment 1 Bob Drzyzgula 2004-03-20 03:55:09 UTC
Created attachment 98705 [details]
Python script which exhibits the problem

Comment 2 Bob Drzyzgula 2004-03-20 04:00:25 UTC
Created attachment 98706 [details]
output of the test.py script on a Fedora Core 1 machine

Note that, at the end, the reference to h['TRIGGERTYPE'] raises a TypeError,
while printing h.sprintf("%{TRIGGERTYPE}") yieds the string "(none)". Note
moreover that  this TRIGGERTYPE is a tag for the termcap package even though
termcap has no triggers. I don't think this should be happening.

Comment 3 Jeff Johnson 2004-03-20 15:47:14 UTC
Hmmm, why do you think there is a tag associated with a
package when you are seeing the value "(none)" returned?

Returning KeyError out of band rather than "(none)" in band
is a design choice. You may agree or disagree with the choice,
but I suggest checking for "(none)" and using what is already
implemented rather than waiting for a more complicated
mechanism that may very well take a year or more to be deployed.

Defererd as an RFE until whenever ...

Comment 4 Bob Drzyzgula 2004-03-20 16:14:18 UTC
The problem is that in these cases is that that tag *is* "associated"
with the package in question, but spuriously. h.keys() returns a list
of tag key numbers for the header, and the TRIGGERTYPE key is being
returned for packages such as termcap that shouldn't have a
TRIGGERTYPE key. If there is no TRIGGERTYPE tag associated with the
package, it shouldn't be listed in h.keys(), but in over 190 packages,
 it is. I discovered this when writing a script that looped through
all tags in all headers on a system with over 1000 packages installed.
The only tag that exhibited this problem was TRIGGERTYPE.

Thus I suspect that the problem is not in the lookup or formatting
code, but rather in the rpmbuild or rpm -I code that generates the
header in the first place; i.e. that this is a symptom of another
problem, not the problem itself.

In fact this is not at the moment causing me difficulty, I can work
around it. But I just thought you might care that somehow rpm is
systematically building corrupted packages.


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