Bug 471359
Summary: | multilib conflicts in dbus and dbus-devel | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Daniel Mach <dmach> | |
Component: | dbus | Assignee: | Dan Williams <dcbw> | |
Status: | CLOSED ERRATA | QA Contact: | desktop-bugs <desktop-bugs> | |
Severity: | medium | Docs Contact: | ||
Priority: | medium | |||
Version: | 5.3 | CC: | atodorov, casmith, cmeadors, davidz, dgregor, jrb, mclasen, ofourdan, syeghiay, tao, tpelka | |
Target Milestone: | rc | |||
Target Release: | --- | |||
Hardware: | All | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Bug Fix | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 614503 (view as bug list) | Environment: | ||
Last Closed: | 2010-03-30 08:22:44 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: | 614503 |
Description
Daniel Mach
2008-11-13 08:30:29 UTC
Dan Williams did the rebase for 5.3, reassigning [note] we have a dbus advisory in the queue for RHEL-5.3: http://errata.devel.redhat.com/errata/show/7847 We can fix the devhelp by using existing pre-generated docs if the tarball shipped with them, which is mclasen's #3. I need to figure out how Fedora fixed the multilib conflict in the service file, but that specific problem will have no *functional* difference between 32 and 64 bit. It won't matter than on a 64-bit machine the 32-bit launch helper might run, since all it does is validate some things and the fork & exec the real program, which itself could be either a 32-bit or 64-bit executable. Acking for the dbus-devel conflicts; the dbus system.conf multilib conflicts are expected and functionally irrelevant. Dan, if the system.conf conflicts don't matter, lets just push it out to 5.4. This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?". I suspect this dbus bug is a bit more important over all than it may seem at first glance. If one is using RH Satellite, the following may happen. Say we install a minimal, clean x86_64 system through Satellite, selecting some Activation Keys to install optional rpms that are needed for third party applications. One of the Activation Keys may request the installation of e.g. 'control-center'. control-center has a dependency on dbus. Since this is a x86_64 system, selecting the 'control-center'-rpm through Satellite's Activation Key feature will pull in both control-center.x86_64 *and* control-center.i386. Because control-center.i386 requires dbus.i386, deployment of this server will _fail_ due to conflicts between the x86_64 (installed through kickstart) and the i386 (install requested through Activation Key) versions of dbus. Mind that Satellite is not able to just install control-center.x86_64 through an Activation Key, nor does it have a forced install mode. Those may be a Satellite bugs on themselves, but that doesn't help us much here. To make a long story short, this dbus bug breaks some Satellite-based deployment scenarios. Can you please push a version of dbus that is not conflicting in this way? (In reply to comment #12) > I suspect this dbus bug is a bit more important over all than it may seem at > first glance. > > If one is using RH Satellite, the following may happen. Say we install a > minimal, clean x86_64 system through Satellite, selecting some Activation Keys > to install optional rpms that are needed for third party applications. > > One of the Activation Keys may request the installation of e.g. > 'control-center'. control-center has a dependency on dbus. Since this is a > x86_64 system, selecting the 'control-center'-rpm through Satellite's > Activation Key feature will pull in both control-center.x86_64 *and* > control-center.i386. Because control-center.i386 requires dbus.i386, deployment > of this server will _fail_ due to conflicts between the x86_64 (installed > through kickstart) and the i386 (install requested through Activation Key) > versions of dbus. What actually pulls in control-center.i386 on an x86-64 system? Can you paste in some of the yum logs that show what's pulling it in? The dbus-devel issues are fixed in dbus-1.1.2-13.el5; the only other conflict that I'm aware of is system.conf, but since that's a %config file I believe that's supposed to be handled in yum/rpm itself? In any case, system.conf is the same between RHEL-5 and F12, and they both mark it as %config, so I have to assume that this is not a problem in F12 and thus the fix (if any) for system.conf would be elsewhere. Control-center.i386 is pulled in by installing control-center via Satellite on RHEL5: both archs get installed when requesting 'control-center'. Satellite has no option to specify a single architecture. For us, this issue seems to be resolved in RHEL5u4, btw. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0236.html |