Bug 407391 - the (inofficial?) "shortest package name wins if multiple ones provides something" rule not honoured properly?
the (inofficial?) "shortest package name wins if multiple ones provides somet...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-01 10:37 EST by Thorsten Leemhuis
Modified: 2014-01-21 18:00 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-04 16:42:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Thorsten Leemhuis 2007-12-01 10:37:19 EST
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 10:38:09 EST
Created attachment 274711 [details]
debug output when running "yum install libGL.so.1"
Comment 2 Jeremy Katz 2007-12-04 16:42:29 EST
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 01:05:54 EST
(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.