Red Hat Bugzilla – Bug 118778
RFE raise KeyError rather than returning "(none)" for header sequence methods
Last modified: 2007-11-30 17:07:00 EST
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@redhat.com 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.
Created attachment 98705 [details] Python script which exhibits the problem
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.
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 ...
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.