+++ This bug was initially created as a clone of Bug #127359 +++ 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: -- Additional comment from skvidal.edu on 2004-07-08 18:24 EST -- samba on rhel3 has it too. and fedora core will have it as well. -- Additional comment from tweeksbugzilla on 2004-07-11 03:53 EST -- 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 -- Additional comment from n3npq on 2006-08-05 05:27 EST -- This is a critical bug that MUST be fixed for rpm to operate correctly with multlib installs. -- Additional comment from fitzsim on 2007-01-22 16:50 EST -- Created an attachment (id=146235) 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. -- Additional comment from fitzsim on 2007-01-22 17:48 EST -- Created an attachment (id=146251) 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} -- Additional comment from fitzsim on 2007-01-22 17:53 EST -- Created an attachment (id=146252) 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} -- Additional comment from n3npq on 2007-01-22 19:52 EST -- 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 ... -- Additional comment from fitzsim on 2007-02-07 14:47 EST -- (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? -- Additional comment from n3npq on 2007-02-07 20:23 EST -- 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. -- Additional comment from n3npq on 2007-02-07 21:34 EST -- Feel free to add comments: https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-February/002073.html -- Additional comment from fitzsim on 2007-02-08 22:13 EST -- 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. -- Additional comment from n3npq on 2007-02-13 20:24 EST -- I'll take that as encouragement ;-) -- Additional comment from fitzsim on 2007-03-09 20:37 EST -- Any updates on this? -- Additional comment from n3npq on 2007-03-12 08:22 EST -- Happening, I just got back from vacation. -- Additional comment from n3npq on 2007-04-29 08:52 EST -- Comment added so that I can find this bug in spite of bugzilla normal -> medium churn. -- Additional comment from pm-rhel on 2007-10-19 15:23 EST -- 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.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Adding patrickm to the cc list as the manager of the disabled user fitzsim who reported this bug
Has there been any progress on this?
Wow.. I'm glad that this bug was pulled of Jeff's plate (or I guess Jeff's leaving). But I've been waiting on this RPM fix since 2004 (see bug Bug #127359). I'm done. Here's my workaround: http://www.ubuntu.com/GetUbuntu/download Tweeks
Can we now stop flaming, please? Thanks.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.