Bug 471359 - multilib conflicts in dbus and dbus-devel
multilib conflicts in dbus and dbus-devel
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dbus (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Dan Williams
desktop-bugs@redhat.com
:
Depends On:
Blocks: 614503
  Show dependency treegraph
 
Reported: 2008-11-13 03:30 EST by Daniel Mach
Modified: 2010-10-23 01:54 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 614503 (view as bug list)
Environment:
Last Closed: 2010-03-30 04:22:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Mach 2008-11-13 03:30:29 EST
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

system.conf:
-  <servicehelper>/lib/dbus-1/dbus-daemon-launch-helper</servicehelper>
+  <servicehelper>/lib64/dbus-1/dbus-daemon-launch-helper</servicehelper>

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.


devhelp:

Problem is, that devhelp docs are autogenerated for each arch and contain different timestamps and URLs.

Example:
-<hr size="1"><address style="align: right;"><small>Generated on Thu Oct 9 11:14:54 2008 for D-Bus by&nbsp;
+<hr size="1"><address style="align: right;"><small>Generated on Thu Oct 9 11:14:58 2008 for D-Bus by&nbsp;

-<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.
Comment 2 David Zeuthen 2008-11-20 13:45:35 EST
Dan Williams did the rebase for 5.3, reassigning
Comment 3 Tomas Pelka 2008-11-20 17:53:35 EST
[note] we have a dbus advisory in the queue for RHEL-5.3:
http://errata.devel.redhat.com/errata/show/7847
Comment 6 Dan Williams 2008-12-03 16:56:56 EST
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.
Comment 7 Dan Williams 2008-12-04 10:40:51 EST
Acking for the dbus-devel conflicts; the dbus system.conf multilib conflicts are expected and functionally irrelevant.
Comment 8 Jonathan Blandford 2008-12-05 13:52:05 EST
Dan, if the system.conf conflicts don't matter, lets just push it out to 5.4.
Comment 10 RHEL Product and Program Management 2009-03-26 12:58:59 EDT
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 "?".
Comment 12 Maxim Burgerhout 2009-07-22 07:35:26 EDT
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?
Comment 14 Dan Williams 2009-12-14 22:03:22 EST
(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?
Comment 15 Dan Williams 2009-12-14 22:57:32 EST
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.
Comment 18 Maxim Burgerhout 2009-12-16 14:50:56 EST
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.
Comment 22 errata-xmlrpc 2010-03-30 04:22:44 EDT
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

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