Bug 2226 - Is this correct to get $2=1 in %triggerpostun?
Summary: Is this correct to get $2=1 in %triggerpostun?
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 5.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-04-17 04:23 UTC by inoue
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-04-22 15:57:10 UTC
Embargoed:


Attachments (Terms of Use)

Description inoue 1999-04-17 04:23:24 UTC
I made a package which is triggerd by another one.  I
expected to get $2=0 in %triggerpostun when removing the
trigger package, but I got $2=1; in %triggerun I got $2=0.
Is this a correct behavior?
--package I made--
%triggerun -- trigger
echo package 1 triggerun:---- $*
%triggerpostun -- trigger
echo package 1 triggerpostun: $*
--trigger I made--
%preun
echo trigger 1 preun:-------- $*
--result I got--
package 1 triggerun:---- 1 0
trigger 1 preun:-------- 0
trigger 1 postun:------- 0
package 1 triggerpostun: 1

Comment 1 Jeff Johnson 1999-04-20 19:20:59 UTC
Can you send me 2 minimal spec files that exhibit the behavior?

------- Email Received From  iNOUE Koich! <inoue.musashi-tech.ac.jp> 04/20/99 19:42 -------

Comment 2 inoue 1999-04-21 05:51:59 UTC
error correction of error I got:
--result I got--
package 1 triggerun:---- 1 0
trigger 1 preun:-------- 0
trigger 1 postun:------- 0
package 1 triggerpostun: 1 1

Comment 3 Jeff Johnson 1999-04-21 18:59:59 UTC
From rpm/docs/triggers:

      ...                       Recall that the $1 passed to regular
scripts contains the number of instances of the package which will be
installed when the operation has completed. $1 for triggers is exactly
the same -- it is the number of instances of the source (or triggered)
package which will remain when the trigger has completed. Similarly,$2
is the number of instances of the target package which will remain. In
this case, if any of the targets will remain after the uninstall, the
trigger doesn't do anything (as it's probably being triggered by an
upgrade).

Identifying in your case:
	"triggered package"	package1
	"target package"	trigger
then the arguments passed to the triggerpostun script are
	$1 is the number of instances of package1
	$2 is the number of instances of trigger
that will be installed on the system after the current operation
completes.

If you were performing an upgrade, then there would be
	1 instance of package1
	1 instance of trigger
installed on the system after the update completes.

So, the arguments appear correct.

Comment 4 inoue 1999-04-21 23:54:59 UTC
> +If you were performing an upgrade, then there would be
> +	1 instance of package1
> +	1 instance of trigger
> +installed on the system after the update completes.
> +
> +So, the arguments appear correct.

But $2 for %triggerun is 0.  What does this mean?

Comment 5 inoue 1999-04-22 00:08:59 UTC
The followings are more complicated sample:
1)package-1-1 has been installed
2)package-1-1 is triggered by trigger-1-1 installation
3)upgraded from trigger-1-1 to trigger-2-2
4)trigger is removed

(no.4 case is the same as what I reported first)

[root@/usr/src/redhat/RPMS/i386]# rpm -q package trigger
package-1-1
package trigger is not installed
[root@/usr/src/redhat/RPMS/i386]# rpm -Uvh trigger-1-1.i386.rpm
trigger 1 pre:---------- 1
trigger 1 post:--------- 1
package 1 triggerin:---- 1 1
[root@/usr/src/redhat/RPMS/i386]# rpm -Uvh trigger-2-2.i386.rpm
trigger 2 pre:---------- 2
trigger 2 post:--------- 2
package 1 triggerin:---- 1 2
package 1 triggerun:---- 1 1
trigger 1 preun:-------- 1
trigger 1 postun:------- 1
package 1 triggerpostun: 1 2
[root@/usr/src/redhat/RPMS/i386]# rpm -e trigger
package 1 triggerun:---- 1 0
trigger 2 preun:-------- 0
trigger 2 postun:------- 0
package 1 triggerpostun: 1 1

Comment 6 Erik Troan 1999-04-22 15:57:59 UTC
This was a bug in RPM; $2 in triggerpostun is always off by 1 :-( This
will be fixed in RPM 3.0.1.

Let me know if you need a patch before then.


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