Red Hat Bugzilla – Bug 210626
Docs/behavior mismatch for triggerpostun
Last modified: 2008-05-06 20:56:55 EDT
If you look at the 'triggers' file in the RPM docs, it gives the order as:
new-%pre for new version of package being installed
... (all new files are installed)
new-%post for new version of package being installed
any-%triggerin (%triggerin from other packages set off by new install)
any-%triggerun (%triggerun from other packages set off by old uninstall)
old-%preun for old version of package being removed
... (all old files are removed)
old-%postun for old version of package being removed
any-%triggerpostun (%triggerpostun from other packages set off by old un
The one marked with >>> doesn't happen.
To reproduce build RPMS from the three attached spec files, and
install/upgrade them in the following sequence:
$ rpm -Uvh trigger-test-source-1-1.noarch.rpm
[ no debug output ]
$ rpm -Uvh trigger-test-target-1-1.noarch.rpm
[ prints ] triggerin 1-1 1 1
$ rpm -Uvh trigger-test-source-2-1.noarch.rpm
[ prints ] triggerin 2-1 2 1
[ prints ] triggerun 1-1 1 1
According to the docs we should have seen
At the end.
If you look in rpm/lib/psm.c, the code that would run that just isn't there.
With PSM_POST, psm->goal == PSM_PKGERASE, PSM_IMMED_TRIGGERS isn't invoked,
though it is in the other cases.
Now, though I think this was likely a code bug orginally - you would
expect %triggerun and %triggerpostun to work the same way and always be
run in pairs, I'm not sure that a code change is possible at
Currently - triggerpostun is only ever run with the source package installed
If it was changed - triggerpostun might be run without the source package installed
So there seems to be some good chance that existing triggerpostun scripts
might not work correctly if they started running at that point in the
Created attachment 138427 [details]
spec file for first test RPM
Created attachment 138428 [details]
Spec file for second test RPM
Created attachment 138429 [details]
Spec file for third test RPM
The doco is as likely to be incorrect as the code is. I wrote that section in 1998.
Is this a real or just an academic problem? If there's a need for
changing trigger behavior in rpm, please supply some hints about
what you are trying to do with %triggerpostun. Otherwise, changing
the doco to conform to existing behavior is certainly easier than otherwise.
The section in the triggers doco was written in order to understand how rpm "worked".
This comment in ypserv/ypserv.spec was added my 1st day working
at Red Hat:
* Fri May 01 1998 Jeff Johnson <email@example.com>
- added triggerpostun
- Use libdb fro dbp_*().
Typos and all.
I'm pretty sure that rpm has never implemented "old-triggerpostun",
but am pefectly willing to remedy that problem, symmetry principles
can lead to robust state machine implementations. Lord knows that
rpm erasures have always been rather flakey.
Anything done in triggerpostun can be done in postun when erasing, the 2 stages are adjacent in the
Meanwhile I've added the changes necessary to make rpm-4.4.8 conform to the doco for symmetry
reasons. I doubt that the change makes any difference, but need to sup on the dog food a bit in order
to verify my claim.
Meanwhile, pango is one of the handful of programs that might benefit from different trigger
semantics, like trigger if any file in a directory is changed.
RFE on <firstname.lastname@example.org> if you're interested in pursuing. I am going to be adding
richer trigger semantics to rpm no matter what.
Thanks for the careful bug report with reproducers.
Sorry - I missed the earlier comments (I tend to get a lot of uninteresting
- I did hit it in real life... basically I was working on a set
of triggers to handle updating an extension symlink in
/usr/lib/firefox-<version> with the approach of:
triggerun: Remove symlinks for all firefox versions present
triggerpostun: Add symlinks for all firefox versions present
Since triggerpostun wasn't run on self upgrade, on self upgrade,
the symlink got removed but not added.
- But as you say, it's easily worked around by duplicating code
between %triggerpostun and %postun instead, with no harm other
than having to comment and explain; that was indeed the approach
(I originally had a much worse workaround involving
running rpm -q | wc in the %triggerun to detect a self-upgrade,
but then came to my senses...)
The spec file I was working on can be found at
Just for the recordf:
This paragraph is in /usr/share/doc/rpm-X.Y/triggers since forever:
There is one other type of trigger available -- %triggerpostun. These are
triggers that are run after their target package has been removed; they will
never be run when the package containing the trigger is removed.
So rpm-4.4.8 no longer conforms to the doco, rpm-4.4.2 does conform to the doco.
I'm happier with the symmetry principle personally ;-)
User email@example.com's account has been closed
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.
If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.
The process we're following is outlined here: