Bug 127359 - $1 argument to scripts should be per-architecture
Summary: $1 argument to scripts should be per-architecture
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rpm
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: multilib 271761 340391
TreeView+ depends on / blocked
 
Reported: 2004-07-07 03:15 UTC by Thomas Fitzsimmons
Modified: 2014-01-21 22:49 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-19 19:23:04 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
patch that introduces new arch-specific pre, post and trigger arguments (11.38 KB, patch)
2007-01-22 21:50 UTC, Thomas Fitzsimmons
no flags Details | Diff
log file showing the upgrade of a test package in the presence of triggers (2.59 KB, text/plain)
2007-01-22 22:48 UTC, Thomas Fitzsimmons
no flags Details
log file showing the upgrade of a test package that contains triggers (1.75 KB, text/plain)
2007-01-22 22:53 UTC, Thomas Fitzsimmons
no flags Details

Description Thomas Fitzsimmons 2004-07-07 03:15:03 UTC
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:

Comment 1 Seth Vidal 2004-07-08 22:24:53 UTC
samba on rhel3 has it too.

and fedora core will have it as well.


Comment 2 Tom Weeks 2004-07-11 07:53:08 UTC
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

Comment 3 Jeff Johnson 2006-08-05 09:27:37 UTC
This is a critical bug that MUST be fixed for rpm to operate correctly with multlib installs.

Comment 4 Thomas Fitzsimmons 2007-01-22 21:50:19 UTC
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.

Comment 5 Thomas Fitzsimmons 2007-01-22 22:48:11 UTC
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}

Comment 6 Thomas Fitzsimmons 2007-01-22 22:53:05 UTC
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}

Comment 7 Jeff Johnson 2007-01-23 00:52:04 UTC
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 ...

Comment 8 Thomas Fitzsimmons 2007-02-07 19:47:44 UTC
(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?


Comment 9 Jeff Johnson 2007-02-08 01:23:44 UTC
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.

Comment 10 Jeff Johnson 2007-02-08 02:34:47 UTC
Feel free to add comments:

   https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-February/002073.html

Comment 11 Thomas Fitzsimmons 2007-02-09 03:13:40 UTC
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.


Comment 12 Jeff Johnson 2007-02-14 01:24:11 UTC
I'll take that as encouragement ;-)

Comment 13 Thomas Fitzsimmons 2007-03-10 01:37:09 UTC
Any updates on this?


Comment 14 Jeff Johnson 2007-03-12 12:22:05 UTC
Happening, I just got back from vacation.

Comment 15 Jeff Johnson 2007-04-29 12:52:39 UTC
Comment added so that I can find this bug in spite of bugzilla normal -> medium churn.

Comment 16 RHEL Program Management 2007-10-19 19:23:04 UTC
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.


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