Red Hat Bugzilla – Bug 471359
multilib conflicts in dbus and dbus-devel
Last modified: 2010-10-23 01:54:05 EDT
File conflicts for:
- /etc/dbus-1/system.conf in dbus-1.1.2-12.el5
- /usr/share/devhelp/books/dbus/api/* in dbus-devel-1.1.2-12.el5
- /usr/share/devhelp/books/dbus/dbus.devhelp in dbus-devel-1.1.2-12.el5
I'm not sure how to fix it.
Do we need multilib dbus package at all?
Only the dbus-daemon-launch-helper path is different when comparing i386 and x86_64.
Problem is, that devhelp docs are autogenerated for each arch and contain different timestamps and URLs.
-<hr size="1"><address style="align: right;"><small>Generated on Thu Oct 9 11:14:54 2008 for D-Bus by
+<hr size="1"><address style="align: right;"><small>Generated on Thu Oct 9 11:14:58 2008 for D-Bus by
-<a name="l00112"></a>00112 ret = <a class="code" href="group__DBusMacros.html#ga93f0eb578d23995850d61f7d61c55c1">FALSE</a>;
+<a name="l00112"></a>00112 ret = <a class="code" href="group__DBusMacros.html#gb5b5527380b5b259294fa10ae7e3a59b">FALSE</a>;
There are several possibilities how to fix it:
1. move devhelp to an arch-specific directory (for example /usr/share/devhelp-<ARCH>)
2. split devhelp to a subpackage which won't be multilib
3. generate docs once (before the actual build) and include the same files in all rpms.
Dan Williams did the rebase for 5.3, reassigning
[note] we have a dbus advisory in the queue for RHEL-5.3:
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.