Bug 131164 - should xorg-x11-Mesa-libGLU be providing libGLU?
should xorg-x11-Mesa-libGLU be providing libGLU?
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2004-08-27 22:22 EDT by Jef Spaleta
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-28 08:11:13 EDT
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 Jef Spaleta 2004-08-27 22:22:27 EDT
Description of problem:
libGLU is not being provided anymore by development x11-org
as compared to the x11-org in FC2.  Is this an oversite or
a "feature"

Development version: xorg-x11-Mesa-libGLU-
->rpm -q --provides xorg-x11-Mesa-libGLU
xorg-x11-Mesa-libGLU =

As a comparison the FC2 version: xorg-x11-Mesa-libGLU-6.7.0-5
->rpm -q --provides xorg-x11-Mesa-libGLU
xorg-x11-Mesa-libGLU = 6.7.0-5

ran into this problem trying to recompile neverball srpm from
fedora.us against rawhide.  Its not my fault I'm addicted to
neverball. I can stop anytime i want to... i just dont want to.

Comment 1 Mike A. Harris 2004-08-28 08:11:13 EDT
There are several scenarios for dependancies for any package on
a library:

1) The package links to a library in another package, and requires
   that library in order to function.  In this case, rpm automatically
   generates the dependancy with find-requires, and nothing should
   be explicitly stated in the spec file.  In this scenario, *any*
   package which happens to provide this library, will satisfy the
   dependancy, regardless of the name of the package.

2) The package links to a library, and requires a specific version
   of the particular implementation's library or greater.  In this
   case, for whatever reasons, the package has decided to hard code
   a dependancy on a specific implementation of the library, and
   requires a certain version-release of the library or higher by
   specifying a "Requires: libfoo >= x.y" in the spec file.  This
   should be avoided in spec files at all costs, as it creates very
   specific dependancies on a specific implementation, often without
   good reason for doing so.  It also makes it much more difficult
   to switch implementations of that library at a future date, and
   if implementations must be switched, and the app works with the
   new implementation, but only the "Requires" fails, this proves
   that the dependancy really was not implementation specific, and
   that the package should have relied on rpm to do the dependancy

No package should have any dependancy on "libGLU", as that is a
bogus dependancy.  The correct thing to do in any case, is to either
let rpm do it's job of specifiying the dependancy, or if a hard
coded dependancy is needed, then specify the implementation, by
doing:  Requires: xorg-x11-Mesa-libGLU >= x.y.z-r

I strongly recommend against implementation specific dependancies
like this however, as they are usually not required, and all
implementations of a given library .so.n should be compatible, which
further makes such deps bogus.

In this case, my recommendation, is to fix the package that is using
the incorrect dependancy, simply by removing the explicit dependancy.

Setting status to "NOTABUG".

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