Bug 150623 - hal update on i386 blocks itself and dbus too
Summary: hal update on i386 blocks itself and dbus too
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: hal   
(Show other bugs)
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-03-08 22:41 UTC by Michal Jaegermann
Modified: 2013-03-06 03:42 UTC (History)
1 user (show)

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


Attachments (Terms of Use)

Description Michal Jaegermann 2005-03-08 22:41:43 UTC
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
....
libhal.so.0  
libhal.so.1  
....

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):
hal-0.5.0-2

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 15:40:24 UTC
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 16:47:56 UTC
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 16:56:24 UTC
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.