Red Hat Bugzilla – Bug 119118
ts.addErase() should handle name.arch correctly
Last modified: 2007-11-30 17:10:38 EST
Description of problem:
When you're adding packages for erasure to the transaction set the
specified arch is accepted but not adhered to.
from the command line rpm -e foo.i386 will remove just the i386 arch
of pkgs named foo.
but ts.addErase('foo.i386') in python will erase all packages named foo.
This seems wrong somehow :)
I don't have a biarch box atm - what happens for the following:
Also just for completeness without setting transaction color:
Expectations imposed on the bindings from the rpm CLI are irrelevant.
The bindings do *exactly* what they've always done becuase that was
the mandate, no change.
Adding implict behavior derived from pattern/string matching on name
and/or arch is asking for trouble. E.g. ts.addErase('kernel.i386')
a) is i386 supposed to archScore or not?
b) are all duplicates to be erased?
Sure conventions can be created, and documented, and it still won't
matter: programmers will *always* differ.
Precise, not loose-goosey DWIM, behavior needs to be the goal
of low level primitives.
NEEDINFO so's I don't have to stare at this bug.
c) should kernel-smp be erased because of Provides: kernel
d) suppose one kernel-smp is elf64, and the other is elf32, and
both have a monkey, rather than automagic, generated
(i.e. the provide is not colored.) Guess what happens?
These are deep issues that cannot be decided with more flexible
syntax. In fact, the flexibility is bound to lead to errors from
To nasrat's question: no change in either case
to jbj's questions: I'm not trying to define loose syntax - I would
like some more control over package erasures from the the python
bindings. I would personally love to be able to say - remove the
package that has THIS HEADER. I'd say an exact header precision should
be pretty strict-fox, not loosey-goosey at all.
i = mi.instance()
permitting both int/string types is mebbe 5 lines of C.
I'll diddle up something today if nasrat doesn't get there first;-)
This is already implemented - mi.instance() is the db offset and addErase takes that.
for h in mi:
if h['arch'] == myarch
Should do what Seth wants, should have been about for a while. Seth can you test
this out please. Adding addErase(h) is probably also doable should you want to
excuse pseudo-python. Tired
That works. After much help from jbj I did some grepping through my
code and found the other place I was calling addErase simply passing
I'm a special type of dumbass.
Let's call this closed and fixed.