Bug 118778 - RFE raise KeyError rather than returning "(none)" for header sequence methods
RFE raise KeyError rather than returning "(none)" for header sequence methods
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rpm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2004-03-19 22:48 EST by Bob Drzyzgula
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-20 10:47:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Bob Drzyzgula 2004-03-19 22:48:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6)

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@redhat.com
under the thread "Python API: TRIGGERTYPE unsupported type".

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

How reproducible:

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

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-19 22:55:09 EST
Created attachment 98705 [details]
Python script which exhibits the problem
Comment 2 Bob Drzyzgula 2004-03-19 23:00:25 EST
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 10:47:14 EST
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 11:14:18 EST
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.