Bug 407391 - the (inofficial?) "shortest package name wins if multiple ones provides something" rule not honoured properly?
Summary: the (inofficial?) "shortest package name wins if multiple ones provides somet...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 8
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-12-01 15:37 UTC by Thorsten Leemhuis
Modified: 2014-01-21 23:00 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-12-04 21:42:29 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
debug output when running "yum install libGL.so.1" (103.68 KB, text/plain)
2007-12-01 15:38 UTC, Thorsten Leemhuis
no flags Details

Description Thorsten Leemhuis 2007-12-01 15:37:19 UTC
Description of problem:
Not sure if this is a bug, but discussing it this way likely is the easiest way.

Livna provides proprietary graphics drivers that have a libGL.so.1 file which is
installed to a different location than the one from mesa-libGL. Thus repoquery
shows this (x86_64 machine, where this bug is triggered more often because some
people uninstall mesa-libGL.i386):

$ repoquery --whatprovides libGL.so.1
xorg-x11-drv-nvidia-libs-32bit-0:100.14.19-4.lvn8.x86_64
xorg-x11-drv-nvidia-96xx-libs-32bit-0:96.43.01-3.lvn8.1.x86_64
xorg-x11-drv-nvidia-legacy-libs-32bit-0:71.86.01-4.lvn8.1.x86_64
mesa-libGL-0:7.0.1-7.fc8.i386

When installing a i386 package that needs that lib mesa-libGL is tracked in (as
it afaik should, as it has the shortest name):

$ sudo yum install wine
[...]
Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Installing:
 wine                    i386       0.9.49-1.fc8     updates            19 k
Installing for dependencies:
 audiofile               i386       1:0.2.6-7.fc8    fedora            107 k
[...]
 libxslt                 i386       1.1.22-1.fc8     fedora            522 k
 mesa-libGL              i386       7.0.1-7.fc8      fedora             11 M
 mesa-libGLU             i386       7.0.1-7.fc8      fedora            203 k
 ncurses                 i386       5.6-12.20070812.fc8  fedora            1.0 M
[...]


But when requesting libGL.so.1 directly yum will chose a different package:

$ sudo yum install libGL.so.1
[...]
Dependencies Resolved
=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Installing:
 xorg-x11-drv-nvidia-libs-32bit  x86_64     100.14.19-4.lvn8  livna            
3.1 M
Installing for dependencies:
 kmod-nvidia-2.6.23.1-49.fc8  x86_64     100.14.19-18.lvn8  livna             2.1 M
 livna-config-display    noarch     0.0.19-2.fc8     livna              64 k
 xorg-x11-drv-nvidia     x86_64     100.14.19-4.lvn8  livna             5.5 M
[...]


Is this expected or a bug?

Version-Release number of selected component (if applicable):
yum-3.2.7-2.fc8

Comment 1 Thorsten Leemhuis 2007-12-01 15:38:09 UTC
Created attachment 274711 [details]
debug output when running "yum install libGL.so.1"

Comment 2 Jeremy Katz 2007-12-04 21:42:29 UTC
This is because your packaging is busted.  You're putting i386 code into an
x86_64 package rather than properly building it as i386.  

The package is getting chosen because better arch is preferred over better name

Comment 3 Thorsten Leemhuis 2007-12-05 06:05:54 UTC
(In reply to comment #2)
> This is because your packaging is busted.  You're putting i386 code into an
> x86_64 package rather than properly building it as i386.  
> 
> The package is getting chosen because better arch is preferred over better name

Ohh, yeah, that explains it -- sorry, I should have thought of this myself.
Well, then we need to find a way to work around that, because "upstream" ships
those 32 bit libs as part of the x86-64 package, and that's why we have them in
there as well.

thx jeremy.



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