Bug 1145192
| Summary: | RFE: Allow install of i686 crash without name conflict on x86_64 arch | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Dave Wysochanski <dwysocha> | ||||
| Component: | crash | Assignee: | Dave Anderson <anderson> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.7 | Keywords: | FutureFeature, Patch | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Enhancement | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-02-10 20:33:29 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Dave Wysochanski
2014-09-22 14:17:27 UTC
Created attachment 940037 [details]
proof of concept patch which just renames 'crash' to 'crash-i686' on i686
Wouldn't your proof of concept also change the name when installing the package on a 32-bit host? We certainly wouldn't want to do that. (Not to mention that your sample crash.spec file is not of the RHEL variety, given that it's got all that "extensions" sub-package crap that only exists in the upstream crash.spec file.) Anyway, I'm not a packaging expert and have no idea how this could (or should) be done. Is there any other RHEL package where this kind of thing is done? To be honest, I always just pull the 32-bit crash binary from its rpm and copy it to /usr/bin/crash32, and don't find that particularly onerous. And this really is primarily because I (and you guys in GSS) find it common to debug the two strains of vmcore on the same machine. I'm not under the impression that this would be of much use to a paying customer. (In reply to Dave Anderson from comment #3) > Wouldn't your proof of concept also change the name when installing > the package on a 32-bit host? We certainly wouldn't want to do that. > Right it's got some flaws but should be fixable. > (Not to mention that your sample crash.spec file is not of the RHEL > variety, given that it's got all that "extensions" sub-package > crap that only exists in the upstream crash.spec file.) > Interesting. I thought I had just pulled from rhel6 dist-git and edited that one part but maybe in the pulling of the upstream tarball I pulled the spec file as well somehow. In any case it builds on rhel6 crash dist-git but could be fixed. > Anyway, I'm not a packaging expert and have no idea how this could > (or should) be done. Is there any other RHEL package where this kind > of thing is done? > I am not sure either. > To be honest, I always just pull the 32-bit crash binary from its rpm > and copy it to /usr/bin/crash32, and don't find that particularly onerous. > And this really is primarily because I (and you guys in GSS) find it > common to debug the two strains of vmcore on the same machine. I'm not > under the impression that this would be of much use to a paying customer. It would be of use to any large customer who has a similar vmcore analysis setup (maybe some TAM customers). I cannot say who that is but there are customers in secure environments which cannot give us vmcores and require us to give them crash commands. If these same customers use 32-bit machines they would want the same functionality so I thought it was worthwhile submitting a bug. Note that retrace-server is public so none of our system is private and anyone can set it up. All that said, I agree it's probably a low # of customers that would want it. Internally we're trying to get away from manual steps in setting up our vmcore analysis system. Right now we have to build our own crash from upstream and patch it with a few things. If this bug is just too nasty then we can do the above workaround when we update it but it's a manual step and people can get it wrong. Just internally I know of 3 unique retrace-server vmcore analysis systems so that's a manual step on all 3 of them. But again, if we're just renaming why not do it in the spec file install step? > Right it's got some flaws but should be fixable.
Well, when you figure out how it could be done, and still pass the errata's
rpmdiff step, tell me how... ;-)
But on the other hand, it's just so trivial to accomplish:
$ rpm2cpio crash-7.0.8-2.el7.i686.rpm | cpio -id --rename ./usr/bin/crash
Although the --rename option is interactive, it's still something that can be
done in a simple shell script as part of your toolset.
And I also don't believe that it should be the only RHEL package that does
such an odd-ball thing.
I'm not the one who has to do this when we need to update crash on the retrace servers, so I can't comment on how much effort this would save. It seems like it isn't much of a pain to unpack the rpm and edit the specfile and rebuild a one-off package. And if as Dave says the only thing we need from the 32bit rpm is the crash executable, that's even simpler. You may want to do it another way, though: 1. Install the 32bit crash rpm, so the 32bit dependencies get installed. 2. Hard-link or copy /usr/bin/crash to /usr/bin/crash32 3. Uninstall 32bit crash 4. Install 64bit crash Since we always do it in a maintenance window, this won't be disruptive. I haven't heard any of our customers mention a need for both arches on one machine. I'm OK with WONTFIX on this one. |