Bug 131164 - should xorg-x11-Mesa-libGLU be providing libGLU?
Summary: should xorg-x11-Mesa-libGLU be providing libGLU?
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-08-28 02:22 UTC by Jef Spaleta
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-08-28 12:11:13 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jef Spaleta 2004-08-28 02:22:27 UTC
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-6.7.99.902-8
->rpm -q --provides xorg-x11-Mesa-libGLU
libGLU.so.1
xorg-x11-Mesa-libGLU = 6.7.99.902-8

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

Note:
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.


-jef

Comment 1 Mike A. Harris 2004-08-28 12:11:13 UTC
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
   setting.

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.