Bug 118778

Summary: RFE raise KeyError rather than returning "(none)" for header sequence methods
Product: Red Hat Enterprise Linux 3 Reporter: Bob Drzyzgula <bob>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED DEFERRED QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: msw, nobody+pnasrat
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-03-20 15:47:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Python script which exhibits the problem
none
output of the test.py script on a Fedora Core 1 machine none

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.