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) new-%triggerin old-%triggerun 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 >>> old-%triggerpostun any-%triggerpostun (%triggerpostun from other packages set off by old un install) 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 'triggerpostun ...' 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 this point. 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 upgrade cycle.
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.
(hysterical aside) 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 <jbj> - 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 state machine. 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 <rpm-devel.duke.edu> 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. UPSTREAM
Sorry - I missed the earlier comments (I tend to get a lot of uninteresting bugzilla noise...) - 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 took. (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 https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139238
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 pnasrat'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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp