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
