Bug 210626 - Docs/behavior mismatch for triggerpostun
Docs/behavior mismatch for triggerpostun
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Panu Matilainen
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-13 09:21 EDT by Owen Taylor
Modified: 2008-05-06 20:56 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:56:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
spec file for first test RPM (489 bytes, text/plain)
2006-10-13 09:23 EDT, Owen Taylor
no flags Details
Spec file for second test RPM (226 bytes, text/plain)
2006-10-13 09:24 EDT, Owen Taylor
no flags Details
Spec file for third test RPM (489 bytes, text/plain)
2006-10-13 09:25 EDT, Owen Taylor
no flags Details

  None (edit)
Description Owen Taylor 2006-10-13 09:21:23 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)
     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.
Comment 1 Owen Taylor 2006-10-13 09:23:31 EDT
Created attachment 138427 [details]
spec file for first test RPM
Comment 2 Owen Taylor 2006-10-13 09:24:16 EDT
Created attachment 138428 [details]
Spec file for second test RPM
Comment 3 Owen Taylor 2006-10-13 09:25:36 EDT
Created attachment 138429 [details]
Spec file for third test RPM
Comment 4 Jeff Johnson 2006-10-14 00:07:58 EDT
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.
Comment 5 Jeff Johnson 2006-10-14 00:43:42 EDT
(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@redhat.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.
Comment 6 Jeff Johnson 2006-10-28 12:31:07 EDT
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@lists.dulug.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
Comment 7 Owen Taylor 2006-10-28 13:00:42 EDT
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
Comment 8 Jeff Johnson 2006-11-25 22:33:15 EST
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 ;-)
Comment 9 Red Hat Bugzilla 2007-08-21 01:27:31 EDT
User pnasrat@redhat.com's account has been closed
Comment 10 Panu Matilainen 2007-08-22 02:34:53 EDT
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Comment 11 Bug Zapper 2008-04-03 14:28:58 EDT
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.
Comment 12 Bug Zapper 2008-05-06 20:56:53 EDT
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

Note You need to log in before you can comment on or make changes to this bug.