libGL and libGLU buildtime dependancy virtualization

[Mike A. Harris]

There are various libGL and libGLU implementations floating
around nowadays and generally speaking, most applications that
link to either library do not require any specific
implementation.

In Red Hat packaging, libGL and libGLU have both moved from 
package to package and subpackage to subpackage over time.  
Applications which link to these libraries do not and should not 
hard code a dependancy on the binary rpm package that provides 
either of these runtime libraries, as rpm's autoreqprov script 
will set the dependancy on the actual library rather than the 
package it is included in.  This has the benefit that as long as 
any implementation of the library is installed on the system via 
rpm, at the same filesystem location as what an application was 
linked to, rpm package installation will be happy, even if you 
have a different libGL installed than was used to link the 
application.

In plain english, building fooGL on a stock Red Hat OS 
installation with all packages installed, will cause fooGL to be 
linked to the Mesa libGL which is included with the X 
implementation included in the OS (either XFree86 or X.Org, 
depending on OS release).  RPM will automatically add a runtime 
dependancy on:

	libGL.so.1

or more accurately on "libGL.so.<version>" that the app was 
linked against.  As long as you have the Red Hat package that 
includes libGL.so.1 installed, the dependancy is met at runtime, 
even if we move libGL to a different package at some point.  
(It's moved from Mesa to XFree86-libs to xorg-x11-libs over the 
years).  Regardless of what package provides this library, all 
apps relying on rpm dependancy checking should be happy.


Problem:

Buildtime dependancies.  In order for your libGL and libGLU
packages to have proper BuildRequires lines that specify all
required build/devel dependancies, you need to specify what
packages provide the needed headers and .so symlinks.  This
causes a problem because the package that includes the libGL and
libGLU headers has changed over the years, and it is possible it
will continue to change in the future from time to time.

If you want to make an rpm package that has all of it's
BuildRequires specified correctly, and links to libGL, and is
buildable on all Red Hat Linux 7.x releases, Red Hat Enterprise
Linux, and Fedora Core 2, you'll have a slight problem, because
the libGL and libGLU headers are in 3 different binary rpms
across that range of OS releases.  Currently, there are 2 ways
people can resolve this in an OS neutral fashion:

1) Specify a build dependancy on the actual header file:
   ie:  BuildRequires: /usr/include/GL/gl.h

or

2) Use rpm macros to select one of 3 different build 
   dependancies, based upon which OS target the package is being 
   built for:

%if %{build_mesaGL}
BuildRequires: Mesa-devel >= 3.4.2
%endif
%if %{build_XFree86_mesaGL}
BuildRequires: XFree86-devel >= 4.2.0
%endif
%if %{build_xorg_x11_mesaGL}
BuildRequires: xorg-x11-devel >= 6.7.0
%endif


>From the two above, #1 is obviously simpler and probably the most 
used.  #1 will also work with any rpm packaged libGL, and not 
just the ones that Red Hat has shipped.

One problem with either approach however, is that it does not 
specify a particular libGL API version, and there is no easy way 
to do so.

Another problem, is that some rpm packagers will put a 
BuildRequires: XFree86-devel to pick up the libGL headers, but 
that will make their rpm package not rebuildable on X.Org, or 
vice versa.

What I am considering doing, to try to solve these problems, is 
to start including virtual provides for libGL-devel from now on 
to all rpm subpackages which provide the libGL development 
headers and symlinks.

Example for X.Org X11 would be adding the following to our 
xorg-x11-devel subpackage dependancy information:

%define libGL_version 1.2
...
Provides: libGL-devel = %{libGL_version}

The same would be done for libGLU, and possibly other libraries.  
RPM packagers could then start using the virtual BuildRequires to
pick up the correct libGL headers, etc.:

BuildRequires: libGL-devel >= 1.2

It would likely take a couple of OS releases before these changes
would catch on, but it's a longterm future-proofing that will
IMHO help keep build dependancies libGL agnostic and X11
implementation agnostic (and agnostic as to wether X11 is
installed at all).

Before I add these changes to our X.Org packaging for FC3 
however, I wanted to hear some constructive feedback and 
other ideas from others.  If I go ahead with the changes, I will 
eventually add similar changes to future updates of XFree86 and 
X.Org X11 for previous OS releases that we still support, so that 
people can start using the virtual provides sooner than later.

Your feedback is appreciated.

TIA

-- 
Mike A. Harris        ftp://people.redhat.com/mharris
OS Systems Engineer   -   X11 Developer   -   Red Hat