Bug 200069 - more complete deps
more complete deps
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mesa (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-25 06:00 EDT by Florian La Roche
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-21 11:23:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Florian La Roche 2006-07-25 06:00:15 EDT
Description of problem:

mesa-libGLw-6.5-13.1.fc6.i386.rpm should have a flag/version added for the
provides (libGLw = 6.5-13.1.fc6)



--- mesa.spec  12 Jul 2006 07:20:09 -0000      1.68
+++ mesa.spec  25 Jul 2006 10:08:29 -0000
@@ -117,7 +117,7 @@ Group: System Environment/Libraries
 Requires(post): /sbin/ldconfig
 Requires(postun): /sbin/ldconfig

-Provides: libGL
+Provides: libGL = %{version}-%{release}

 # libGL used to be in Mesa package in RHL 6.x, 7.[0-2], RHEL 2.1
 Obsoletes: Mesa
@@ -139,7 +139,7 @@ Group: Development/Libraries
 Requires: mesa-libGL = %{version}-%{release}
 Requires: libX11-devel

-Provides: libGL-devel
+Provides: libGL-devel = %{version}-%{release}

 # libGL devel files were in Mesa-devel package in RHL 6.x, 7.[0-2], RHEL 2.1
 Obsoletes: Mesa-devel
@@ -158,7 +158,7 @@ Group: System Environment/Libraries
 Requires(post): /sbin/ldconfig
 Requires(postun): /sbin/ldconfig

-Provides: libGLU
+Provides: libGLU = %{version}-%{release}

 # libGLU used to be in Mesa package in RHL 6.x, 7.[0-2], RHEL 2.1
 Obsoletes: Mesa
@@ -180,7 +180,7 @@ Group: Development/Libraries
 Requires: mesa-libGLU = %{version}-%{release}
 Requires: libGL-devel

-Provides: libGLU-devel
+Provides: libGLU-devel = %{version}-%{release}

 # libGLU devel files were in Mesa-devel package in RHL 6.x, 7.[0-2], RHEL 2.1
 Obsoletes: Mesa-devel
@@ -199,7 +199,7 @@ Group: System Environment/Libraries
 Requires(post): /sbin/ldconfig
 Requires(postun): /sbin/ldconfig

-Provides: libGLw
+Provides: libGLw = %{version}-%{release}

 # libGLw used to be in Mesa package in RHL 6.x, 7.[0-2], RHEL 2.1
 Obsoletes: Mesa
@@ -216,7 +216,7 @@ Summary: Mesa libGLw development package
 Group: Development/Libraries
 Requires: libGLw = %{version}-%{release}

-Provides: libGLw-devel
+Provides: libGLw-devel = %{version}-%{release}

 # libGLw devel files were in Mesa-devel package in RHL 6.x, 7.[0-2], RHEL 2.1
 Obsoletes: Mesa-devel
@@ -457,6 +457,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_bindir}/glxinfo

 %changelog
+* Tue Jul 25 2006 Florian La Roche <laroche@redhat.com>
+- add version/release to Provides:
+
 * Wed Jul 12 2006 Jesse Keating <jkeating@redhat.com> - sh: line 0: fg: no job
control
 - rebuild



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Mike A. Harris 2006-07-25 08:14:24 EDT
The "libGL", "libGL-devel", "libGLU", "libGLU-devel" and similar virtual
provides that are present in the mesa packaging are intentionally non-versioned.

Many different OpenGL implementations exist out in the wild currently, and
Mesa's is only one of them.  Most software packages that use OpenGL, are
capable of building against _any_ of the implementations that exist, and
are not dependent on a specific implementation.

The desire to be able to specify a build and/or runtime dependency on an
arbitrary OpenGL implementation was part of the design of the modular
mesa packaging.  This was achieved by providing a number of unversioned
virtual provides in the package which 3rd party software could then depend
on in an implementation-agnostic manner.

So if a package requires "some" libGL implementation, it should use the
following:

BuildRequires: libGL-devel

Any OpenGL implementation which happens to be installed from rpm maintained
packages should provide the "libGL-devel" and other virtual provides as well.
This allows the OpenGL implementation to be changed easily, and helps to
keep all rpm packaged software which depends on OpenGL to be implementation
agnostic.

For this reason, these virtual provides intentionally do not contain a
version or version-release string, as that would defeat the purpose for
which the virtual provides exist for.  The version of the mesa package
itself, is only relevant specifically to mesa, not to OpenGL.

If a software package uses GL extensions or other features which are
unique to the Mesa implementation, then the software package should be
depending directly on the Mesa implementation of OpenGL by doing:

BuildRequires: mesa-libGL-devel >= 6.5-4     (or whatever is relevant)

Likewise, if a given software package requires extensions that are only
available in Nvidia's OpenGL implementation, it should use:

BuildRequires: nvidia-libGL-devel >= <version-release>

(or whatever the livna nvidia libGL-devel package is called).

The same holds true for the libGLU and libGLw libraries.  If a software
package needs a specific "version" of any of these 3 libraries, that alone
implies that the software is also dependent on a specific implementation
of the given library, as the versioning of different implementations is
itself unique.

There is one theoretical case which the current packaging does not cover,
which as of yet has not come up in practice, but which would not be
difficult to solve in the future if the need arises.  Should there be
new generic OpenGL functionality which a software package requires, which
was not previously available in a given libGL implementation - such as a
new ARB GL extension or whatever, that extension would exist in more than
one implementation, however each implementation has it's own software
release versioning scheme.  If the need arises to solve this problem in
practice, we could add the actual libGL API version (1.2, 2.0, etc.) to
the virtual provide, or create a new provide such as:

Provides: libGL-api = 1.2
Provides: libGL-abi = 1.2

etc.

Another possibility, is to add virtual provides for individual extensions.

Provides: libGL-ext-<extension-name> = x.y

In practice, the current solution solves the problems it was designed to
solve, without becoming over-designed and complex.


In closing:  If someone is wanting to depend on a specific libGL version,
they should either be depending on versioned mesa-libGL-devel instead, or
if it is an implementation agnostic issue which requires a newer GL extension
or something, they should file a very clear specific bug against mesa
describing the issue, and we will review it and try to come up with a good
generic long-term solution.

I will add comments to the mesa spec file to clarify the purpose of the
virtual provides it contains.

Closing as NOTABUG.
Comment 3 Florian La Roche 2007-06-21 11:23:14 EDT
Doesn't apply anymore to current packages.

regards,

Florian La Roche

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