Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 150623 - hal update on i386 blocks itself and dbus too
hal update on i386 blocks itself and dbus too
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
Depends On:
  Show dependency treegraph
Reported: 2005-03-08 17:41 EST by Michal Jaegermann
Modified: 2013-03-05 22:42 EST (History)
1 user (show)

See Also:
Fixed In Version: 0.5.0-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-09 10:40:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2005-03-08 17:41:43 EST
Description of problem:

$ rpm -V hal-0.5.0-2.i386
Unsatisfied dependencies for hal-0.5.0-2.i386: libhal.so.0
$ rpm -qR hal-0.5.0-2.i386

and hal-0.5.0-2.i386 provides only /usr/lib/libhal.so.1.
A resulting mess is rather difficult to untangle and requires
quite a bit of a manual intervention.

Version-Release number of selected component (if applicable):

How reproducible:
With hal-0.5.0-2.i386 only but, unfortunately, this is used
on x86_64 too.
Comment 1 David Zeuthen 2005-03-09 10:40:24 EST
This is now fixed in Rawhide - my guess is that it's a libtool of some
sort (it picked up the libhal.so.0 dep from the buildroot) since I've
seen this with other packages.
Comment 2 Michal Jaegermann 2005-03-09 11:47:56 EST
I agree that this is prolly something in libtool and force-installing
required pieces followed by a rebuild most likely fixes the problem
locally.  But the same trouble shows in other places too (see,
for example, bug #150155) which probably means that the same issue
will haunt you in release updates as well.

Interestingly enough I did not see that to happen yet with x86_64
packages (which have _other_ libtool gotchas).  So what is different
and where this should be re-filed?  Mending particular occurences does
not seem like a good answer.
Comment 3 David Zeuthen 2005-03-09 11:56:24 EST
Yeah, it's something with libtool but all the auto*/libtool magic
sometimes escape me. It would be good to make a test case and file it
against libtool to fix the once and for all.

Btw, for updates in stable release that including bumping of sonames
(which is rare since it means ABI breakage) this will probably be
caught by QA'ing the package. 

It would be good to fix this nonetheless.

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