On Apr 14, 2008, at 11:26 AM, Ralf S. Engelschall wrote:

> Perhaps I got already totally crazy during all my RPM 5 tests, but I
> have a Makefile in which is used "rpm -Uvh --replacepkgs" in order
> to install or re-install (even with the same NEVRA) a package. With
> 5.1b2 the --replacepkgs was sufficient to reinstall a package, but
> with 5.1.0 I now needed an additional --oldpackage. I mean, I can live
> with this, but (1) I do not understand why this is now different and
> (2) the question is whether we are OK with this (new) behaviour or (3)
> whether --replacepkgs has to be fixed now. It's just a minor issue,  
> but
> I wanted to let it recognized in case it is a bug. You can  
> reproduce it
> by reinstalling a package (hopefully any package works and that it  
> isn't
> related to my particular package).
>

The flaw with "release.arch" instead of just "release" that fixed your
previous problem of too many *.rpmorig/*.rpmnew files being created
is in exactly the same place that --oldpackage and --replacepkgs checks
are implemented. I will verify (by checking older rpm releases) that  
the behavior
is as always.

Meanwhile, is there any real purpose in continuing to force users
to specify additional arguments in order to override some hoary
concept of upgrade based solely on EVR comparison to determine "newer"?

Another rpm CLI flaw is that --install is very much the wrong option  
to use.
In almost every case --upgrade behavior is what is expected and
desired. I have to explain the difference at least weekly: --upgrade  
== --install when
there is no previously installed package. otoh --install when used  
wrongly
invariably leads to multiple instances of a package installed.

I'd rather change rpm behavior than explain the difference for  
another decade.

(OT aside) %config changing discussion soonishly, lemme whack  
together a proof-of-concept
implementation first.

73 de Jeff