From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040301 Description of problem: We use alternatives to manage the JVMs we ship with RHEL3. On ppc64 it is possible to install both the ppc IBM JVM and the ppc64 IBM JVM in parallel as alternatives. The rpms' %postun scripts look like this: %postun if [ "$1" = "0" ]; then update-alternatives --remove java %{jrebindir}/java update-alternatives --remove jre_%{origin} %{_jvmdir}/%{jredir} update-alternatives --remove jre_%{javaver} %{_jvmdir}/%{jredir} fi If both the 32-bit and 64-bit JVM packages are installed in parallel and one is uninstalled, the first argument to %postun ($1) is 1. That means that the update-alternatives commands are not run and so the symlinks for the uninstalled alternative are not removed. Currently, the package count passed to %postun ($1) represents the number of packages that will be installed when the script ends. Instead, it should represent the number of packages that will be installed for %{_arch} when the script ends, where %{_arch} is the uninstalled package's architecture. Version-Release number of selected component (if applicable): rpm-4.2.2-0.14 How reproducible: Always Steps to Reproduce: 1. install 32-bit and 64-bit IBM ppc JVM packages in parallel 2. uninstall 32-bit packages Actual Results: 32-bit alternatives symlinks are still present Expected Results: 32-bit alternatives symlinks should have been removed Additional info:
samba on rhel3 has it too. and fedora core will have it as well.
I see the same type problem on EL3 with trying to install the "arts" package on a 64 bit system (opteron). Esp when a system has a dependancy... To satisfy the dep.. I've actually have to move over to a 32 bit system, up2date DL the 32 bit bin-rpm, move it over to the 64 bit system and install it over top the 64 bit version, because the dep being required was the 32 bit dep.. not the /usr/lib64/ arts library. This is INSANE because now it breaks the /usr/bin/ files. RPM can't diff between the packages and needs to be fixed.. and some better dual arch. system needs to be created (or fixed) so that dual mode systems (like the Opteron) will even work. If people start "fixing" these packages manually... over time, up2date will be stunted and ineffective (because of manual overriding/fixing). Has no one else brought this up before? Surely I can't be the first... Is this a dup of an open bug elsewhere? I saw something in the fonts section that was being caused by this same underlying flaw in RPM also. Tweeks
This is a critical bug that MUST be fixed for rpm to operate correctly with multlib installs.
Created attachment 146235 [details] patch that introduces new arch-specific pre, post and trigger arguments Here's a preliminary patch for this issue, against Rawhide rpm. The patch changes the number of arguments passed to pre, post and trigger scripts in a backwards-compatible way. For pre and post scripts, it adds a $2 argument that represents the number of packages that will be installed for %{_arch} when the transaction ends. For trigger scripts, it adds two extra arguments: the arch-dependent equivalents of the current $1 and $2 trigger arguments. No currently-deployed pre or post script should interpret the value of $2 nor should any trigger script rely on $3 and $4 (I confirmed this for all the pre, post and trigger scripts installed on my FC-6 system). Because this patch does not change the existing meanings of $1 (pre, post) and $2 (trigger) it will allow a smooth migration for packages wanting to switch. It also maintains the old syntax, for scripts that need not be architecture-aware, for example scripts that modify arch-independent files shared between multilib packages. In addition to changing the interface seen by package scripts, this patch introduces some ABI changes: 1) Two new fields in the rpmpsm_s structure: npkgs_installed_arch and scriptArgArch 2) One new function in librpmdb: rpmdbCountPackagesArch If I receive positive feedback on this approach or some similar approach then I'll complete and resubmit the patch (including documentation, test cases, splint annotations, proper indentation). I'll also attach two log files that demonstrate how the new arguments work.
Created attachment 146251 [details] log file showing the upgrade of a test package in the presence of triggers This log file shows the script argument values when upgrading testarch.i386 and testarch.x86_64 in the same transaction. The test package has prein, postin, preun and postun scripts of the form: echo testarch.%{_arch} pre: echo '$1' = $1 = testarch echo '$2' = $2 = testarch.%{_arch}
Created attachment 146252 [details] log file showing the upgrade of a test package that contains triggers This log file shows the script argument values when upgrading testarchtrigger.i386 and testarchtrigger.x86_64 in the same transaction. The test packages have prein, postin, preun and postun scripts of the form: echo testarchtrigger.%{_arch} pre: echo '$1' = $1 = testarchtrigger echo '$2' = $2 = testarchtrigger.%{_arch} and triggerin, triggerun and triggerpostun scripts of the form: %triggerin -- testarch echo testarchtrigger.%{_arch} triggerin: echo '$1' = $1 = testarchtrigger echo '$2' = $2 = testarch echo '$3' = $3 = testarchtrigger.%{_arch} echo '$4' = $4 = testarch.%{_arch}
Um, really all that is needed is a decision to change $1 and $2 to be per-arch. In fact that preserves erasures with existing packages on multilib far better than addinbg 2 more arguments. BTW, scriptlets can have args like $post -p "/sbin/ldconfig -n /usr/lib" many years now. And truly, the vast majority of usage is %preun/%postun differentiating pure erasure from erasure-due- to-upgrade. A single envvar that has 2 values would achieve that far far more easily. BTW, rpmdbSetIteratorRE() is pig slow serialization, way too many headerLoad's just to do a strcmp. But let me see if I can save some of what you've done. Lord knows its way past time to attempt a fix ...
(In reply to comment #7) > But let me see if I can save some of what you've done. Lord knows its way past time to attempt a fix ... Any progress on this?
Not yet, I got distracted. Lemme put a post onto rpm-devel about changing the existing args to be per-arch. Very little will break, and adding 4 args for triggers just makes me want to cry. The other issue is speed, the per-arch count using a arch pattern can be accomplished in other ways. The easiest hack is to add elf32/elf64 bits to the header instance, basically instance <<= 2 instance |= color so that the join keys themselves can be used to track elf32/elf64, avoiding a sequential search with repeated header loads in order to access the arch string. I'm still muddling about whether I will regret stealing 2 bits from an otherwise opaque join key.
Feel free to add comments: https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-February/002073.html
I like the simplicity of a boolean environment variable, and an Arch index seems like a clean optimization. And I think the number of packages in Fedora that would need to be changed to support a new environment variable is definitely manageable.
I'll take that as encouragement ;-)
Any updates on this?
Happening, I just got back from vacation.
Comment added so that I can find this bug in spite of bugzilla normal -> medium churn.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.