Bug 119118 - ts.addErase() should handle name.arch correctly
Summary: ts.addErase() should handle name.arch correctly
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
(Show other bugs)
Version: 1
Hardware: All Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-25 06:48 UTC by Seth Vidal
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-03 19:16:33 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Seth Vidal 2004-03-25 06:48:23 UTC
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 :)

Comment 1 Paul Nasrat 2004-03-27 08:20:52 UTC
I don't have a biarch box atm - what happens for the following:

Also just for completeness without setting transaction color:


Comment 2 Jeff Johnson 2004-03-27 23:35:53 UTC
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.

Comment 3 Jeff Johnson 2004-03-27 23:40:27 UTC
  c) should kernel-smp be erased because of Provides: kernel

Comment 4 Jeff Johnson 2004-03-27 23:46:11 UTC
  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.

Comment 5 Seth Vidal 2004-04-02 06:28:07 UTC
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.

Comment 6 Jeff Johnson 2004-04-02 19:33:53 UTC
Ah,ok. permitting
    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;-)

Comment 7 Paul Nasrat 2004-04-03 16:46:06 UTC
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 
mirror addInstall.

Comment 8 Paul Nasrat 2004-04-03 16:47:58 UTC
excuse pseudo-python.  Tired

Comment 9 Seth Vidal 2004-04-03 19:16:33 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.