Bug 127359
Summary: | $1 argument to scripts should be per-architecture | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Thomas Fitzsimmons <fitzsim> |
Component: | rpm | Assignee: | Panu Matilainen <pmatilai> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | CC: | 64bit_fedora, herrold, k.georgiou, msw, nobody+pnasrat, overholt, redhat-bugzilla, tweeksbugzilla |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-10-19 19:23:04 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 235752, 271761, 340391 | ||
Attachments: |
Description
Thomas Fitzsimmons
2004-07-07 03:15:03 UTC
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. |