This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 340391 - $1 argument to scripts should be per-architecture
$1 argument to scripts should be per-architecture
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
19
All Linux
medium Severity medium
: ---
: ---
Assigned To: Fedora Packaging Toolset Team
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On: 127359
Blocks: 484858
  Show dependency treegraph
 
Reported: 2007-10-19 15:41 EDT by Thomas Fitzsimmons
Modified: 2015-02-18 06:56 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-18 06:56:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Thomas Fitzsimmons 2007-10-19 15:41:52 EDT
+++ 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@linux.duke.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@theweeks.org 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@mac.com 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@redhat.com 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@redhat.com 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@redhat.com 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@mac.com 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@redhat.com 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@mac.com 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@mac.com 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@redhat.com 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@mac.com on 2007-02-13 20:24 EST --
I'll take that as encouragement ;-)

-- Additional comment from fitzsim@redhat.com on 2007-03-09 20:37 EST --
Any updates on this?


-- Additional comment from n3npq@mac.com on 2007-03-12 08:22 EST --
Happening, I just got back from vacation.

-- Additional comment from n3npq@mac.com 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@redhat.com 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.
Comment 1 Bug Zapper 2008-05-13 23:26:48 EDT
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
Comment 2 Red Hat Bugzilla 2008-07-24 21:04:02 EDT
Adding patrickm@redhat.com to the cc list as the manager of the disabled user fitzsim@redhat.com who reported this bug
Comment 3 Lillian Angel 2008-11-12 10:06:20 EST
Has there been any progress on this?
Comment 4 Tom Weeks 2008-11-16 01:52:34 EST
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
Comment 5 Robert Scheck 2008-11-16 07:41:42 EST
Can we now stop flaming, please? Thanks.
Comment 6 Bug Zapper 2009-06-09 18:58:21 EDT
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
Comment 7 Bug Zapper 2009-07-14 10:33:52 EDT
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.
Comment 8 Bug Zapper 2009-11-16 02:58:26 EST
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
Comment 10 Bug Zapper 2010-11-04 08:05:23 EDT
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
Comment 11 Bug Zapper 2010-12-05 02:14:29 EST
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.
Comment 13 Fedora Admin XMLRPC Client 2012-04-13 19:12:44 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 14 Fedora Admin XMLRPC Client 2012-04-13 19:14:07 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 15 Fedora End Of Life 2013-04-03 15:55:55 EDT
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
Comment 16 Fedora End Of Life 2015-01-09 16:36:06 EST
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.
Comment 17 Fedora End Of Life 2015-02-18 06:56:48 EST
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.

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