Bug 119118
| Summary: | ts.addErase() should handle name.arch correctly | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Seth Vidal <skvidal> |
| Component: | rpm | Assignee: | Jeff Johnson <jbj> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1 | CC: | nobody+pnasrat |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-04-03 19:16:33 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: | |||
I don't have a biarch box atm - what happens for the following:
ts.setColor(1)
ts.addErase('foo.i386')
Also just for completeness without setting transaction color:
ts.addErase('foo.x86_64')
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
Provides: kernel
(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
DWIM expectations.
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. Ah,ok. permitting
i = mi.instance()
ts.addErase(i)
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.
ts=rpm.ts()
mi=ts.dbMatch("foo")
for h in mi:
instance=mi.instance()
if h['arch'] == myarch
ts.addErase(instance)
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
mirror addInstall.
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 it name. I'm a special type of dumbass. Let's call this closed and fixed. |
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 :)