Opened 9 years ago

Closed 4 years ago

#30 closed defect (wontfix)

WPS objects are killed on package update

Reported by: dmik Owned by: Yuri Dario
Priority: major Milestone:
Component: rpm Version:
Severity: highest Keywords:


If a package creates some WPS objects in %post and deletes them in %postun, updating such a package to a new version kills all WPS objects as if the package was uninstalled.

Change History (5)

comment:1 Changed 9 years ago by dmik

This happens because the order in which %pre and %post sections of the old and new package are executed in RPM is weird. Given that the currently installed package version is "Old" and the version it is being updated to is "New", a sane person would expect the following sequence:

%pre of New
%preun of Old
%postun of Old
%post of New

Or at least:

%preun of Old
%postun of Old
%pre of New
%post of New

However, in reality it is as follows (the number in square braces is the value of the $1 parameter which is claimed to be "a count of the number of versions of the package that are installed", according to RPM Guide, just for reference).

Installing version "Old" of the package:

%pre of Old [1]
%post of Old [1]

Updating to version "New":

%pre of New [2]
%post of New [2]
%preun of Old [1]
%postun of Old [1]

Removing the package:

%preun of New [0]
%postun of New [0]

So it's not a surprise that the WPS objects are killed: the %post section of the New package (which creates WPS objects) is called before the %postun section of the old package (which deletes them). This is completely out of logic.

Last edited 9 years ago by dmik (previous) (diff)

comment:2 Changed 9 years ago by dmik

An obvious solution is to only delete WPS objects in %postun if $1 is 0 (i.e. the last version of the package is removed). When it is not 0, it's not a removal, it's an update, and the objects should not be deleted. This, in turn, means that when creating objects in %post, we should first delete them if $1 is not 0 (i.e. upon update) and only after that create them again (to make sure the old objects not intended to exist after the update will go away). Quite cumbersome.

This actually applies to any other setting (e.g. CONFIG.SYS change, INI change, etc, etc, etc). This looks like a clear RPM design flaw to me.

Yuri, can we embed our own scriptlets in RPM? I would like to have it fixed, if possible, using alternative scriplets, like %sane-pre|post -)

Last edited 9 years ago by dmik (previous) (diff)

comment:3 Changed 9 years ago by dmik

Just for the record, yum reinstall gives the following sequence:

%pre of New [2]
%post of New [2]

This is also strange, since the sane person would expect that reinstall does uninstallation followed by installation but that's not the case. It's just a forced installation as if the package were not installed. IMHO this is wrong too.

comment:4 Changed 9 years ago by dmik

I fixed this for the Odin RPMs. Needs to be fixed for Qt and Qt Creator RPMs as well.

I also added the section where this technique is described too.

comment:5 Changed 4 years ago by Silvan Scherrer

Resolution: wontfix
Severity: highest
Status: newclosed

as this is nicely documented and the workaround works, I close the ticket. As I seriously doubt we will ever create our own script for that.

Note: See TracTickets for help on using tickets.