Bugzilla – Bug 774358
zypper handles transaction incorrectly and executes scripts in wrong order (%pretrans, %posttrans )
Last modified: 2012-10-24 06:52:46 UTC
Created attachment 501019 [details] Tarball containg RPMs used in described example. Including source RPMs. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0 Assume two packages: test and dep, test requires dep (Requires: dep). To not break package dependencies both packages must be installed within the same transaction. The required (and documented) behavioral is to execute scripts in the following order: $ sudo rpm -i test-1.0.0-1.noarch.rpm dep-2.0.0-1.noarch.rpm dep pretrans test pretrans dep pre dep post test pre test post dep posttrans test posttrans Zypper executes scripts in a different manner (especially %pretrans and %posttrans): $ sudo zypper install test-1.0.0-1.noarch.rpm dep-2.0.0-1.noarch.rpm Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW packages are going to be installed: dep test 2 new packages to install. Overall download size: 6.0 KiB. After the operation, additional 2.0 KiB will be used. Continue? [y/n/?] (y): y Retrieving package dep-2.0.0-1.noarch (1/2), 3.0 KiB (1.0 KiB unpacked) Retrieving package test-1.0.0-1.noarch (2/2), 3.0 KiB (1.0 KiB unpacked) Retrieving package dep-2.0.0-1.noarch (1/2), 3.0 KiB (1.0 KiB unpacked) Installing: dep-2.0.0-1 [done] Additional rpm output: dep pretrans dep pre dep post dep posttrans Retrieving package test-1.0.0-1.noarch (2/2), 3.0 KiB (1.0 KiB unpacked) Installing: test-1.0.0-1 [done] Additional rpm output: test pretrans test pre test post test posttrans Reproducible: Always Steps to Reproduce: Install attached RPMs and see results on screen. $ sudo zypper install test-1.0.0-1.noarch.rpm dep-2.0.0-1.noarch.rpm Actual Results: Order of scripts executed is: 1. dep pretrans 2. dep pre 3. dep post 4. dep posttrans 5. test pretrans 6. test pre 7. test post 8. test posttrans Expected Results: Compare zypper results with plain rpm command that uses right ordering. $ sudo rpm -i test-1.0.0-1.noarch.rpm dep-2.0.0-1.noarch.rpm 1. dep pretrans 2. test pretrans 3. dep pre 4. dep post 5. test pre 6. test post 7. dep posttrans 8. test posttrans See also: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets
Actually all scripts are executed by rpm, but we invoke rpm to install single packages. Using larger transactions has some cons, OTOH we currently can't tell rpm not to execute any %trans, so zypp itself can't collect and execute them. So we have to see how to solve this best.
Are there examples of packages that actually depend on this interleaved scriptlet ordering? Is it good practice to require two packages to be installed in the same transaction? I understand it being possible, but I do not understand it being required. My expectation is that installing dep before test using two rpm transactions will successfully install the packages in the same way as installing them using one transaction. Or am I missing something?
The result should not be different, but the amount of pre/posttrans calls is. If you e.g. have 3000 TeX related packages, all of them calling texconfig/update in their posttrans, you feel the difference. *** This bug has been marked as a duplicate of bug 773575 ***
Well not exactly. I agree that in most cases the result should be the same, but could also be different, depends on what is in the test pretrans script. E.g. Nagios and Ganglia add user accounts in the pre script if they are not already present. The ID is not specified and chosen by useradd. Sometimes it is desirable to have the ID fix, e.g. in a failover scenario that involves more than one host. If the Nagios or Ganglia RPM is installed as a dependency of another RPM it would be possible to create that user account with a fix ID in the pretrans script. This is currently not possible with zypper because it runs the pretrans script after all the scripts in the depending RPM. Yum handles these scenario correctly.
Uh, you can't do such things in the pretrans script, as "useradd" is not available in an empty system. Basically all pretrans scripts must be written in lua.
The packages I spoke about are typically added to a fully installed host not an empty system. And I guess are also not part of a "from scratch" installation transaction. The useradd thing should only serve as an example and has nothing to do with the basic problem.