[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpmorg-list
Subject:    Re: Problems with %post macros.
From:       bob () proulx ! com (Bob Proulx)
Date:       2005-06-11 18:23:13
Message-ID: 20050611182313.GD3267 () dementia ! proulx ! com
[Download RAW message or body]

Hal Wine wrote:
> See the bottom of the file 'triggers', which should be in 
> /usr/share/doc/rpm-*/. It has the clearest description of the macro 
> execution order on update I've found. Earlier parts of the file give 
> examples on how to know if you're the "last" uninstall.

The triggers file is good documentation.  But even so I find the
following example to be even more clear and so decided to share it.

Assume an install upgrade cycle from 1.0-0 to 2.0-0 to 3.0-0 and the
following are the versions of the pre and post install scripts run
through those operations.  The number on the right is the $1 parameter
passed to those scripts.

  Install 1.0-0
    pre    1.0-0  1
    post   1.0-0  1

  Upgrade 2.0-0
    pre    2.0-0  2
    post   2.0-0  2
    preun  1.0-0  1
    postun 1.0-0  1

  Upgrade 3.0-0
    pre    3.0-0  2
    post   3.0-0  2
    preun  2.0-0  1
    postun 2.0-0  1

  Erase 3.0-0
    preun  3.0-0  0
    postun 3.0-0  0

This is one of the reasons it is very important to test package
upgrade paths on newly created rpm packages.  This is easy to miss an
error in the first version of a package and hard to correct in later
version of the package.

Even though I am well aware of the problem I missed exactly this in a
crosscheck of a colleagues rpm file just a week ago and then we had to
dance around the problem manually to fix the resulting issue.
Fortunately the scope of distribution was just our local group and not
hard to manage.

This is also the reason many, usually 3rd party, rpm packages found on
the net require an --erase before an install of the new version and
why they can't be --upgrade'd.  Probably an error exists in their
postun script which is removing something important to the package.
Since that is run last it can't be prevented through normal means.
Testing the package upgrade path would have found the problem before
releasing the first version of the package.

Bob

[prev in list] [next in list] [prev in thread] [next in thread]