[Rpm-maint] Package replace implementation

[Panu Matilainen]

On 06/08/2011 06:49 PM, Michael Schroeder wrote:
>
> Hi,
>
> seeing the latest "replacepkgs" commits (030e54), I wonder if we
> should not drop that crazy refresh handling and simply use an
> uninstall element to erase the package.

Nod, I've been thinking of doing that for some time now. I did look at 
it at some point (maybe last year) but can't remember what exactly 
stopped me, there might've been something that made it harder than it 
seems on the outset. Anyway, doing a reinstall/refresh just like it was 
an regular update seems like a much saner way to handle it.

> Currently, rpm works different if the EVR of the to-be-installed
> package matches the installed package:
>
> foo-1-2 ->  foo-1.3   (upgrade)
>    - run prein/postin of foo-1.3
>    - run preun/postun of foo-1.2
>
> foo-1-2 ->  foo-1.1   (downgrade)
>    - run prein/postin of foo-1.1
>    - run preun/postun of foo-1.2
>
> foo->1.2 ->  foo-1.2  (replace)
>    - run prein/postin of foo-1.2
>    - does *not* run uninstall scriptlets or deinstall files no
>      longer in foo-1.2
>
> Why doesn't it run the uninstall scriptlets? What makes "same EVR"
> so special when the package content may be different nevertheless?

No idea what the original reason for this behavior is, or how much of it 
is intentional and what's not. I've tried to keep it "like it always 
was" but it's of course possible some subtle behavior changes have crept 
in, hard to test when you don't even know what exactly it is /supposed/ 
to be doing wrt scriptlets and the like.

It is actually harmful too in some cases: since there's no clean way to 
upgrade package architecture within the same evr (eg glibc-x.y-z.i386 -> 
glibc-x.y-z.i686), you're forced to use --replacepkgs (and 
--replacefiles) which can leave leftover files behind and in the glibc 
case I'm thinking of (somewhere in RH bugzilla), this was rather fatal.

	- Panu -