Heads up for 3rd party libGL/libGLU rpm packagers (ie: nvidia, ati)

[Mike A. Harris]

xorg-x11-Mesa-libGL now has a virtual provide of:

Provides: libGL = 1

Likewise, xorg-x11-Mesa-libGLU has a virtual provide of:

Provides: libGLU = 1


The reason for these additions should be obvious, but in
case it isn't, these have been added, so that packages
providing the development environments for these libs,
can "Requires: libGL >= 1" and be confident that the
build time dependancies are all properly met.  The reason
for a virtual provide/require instead of an explicit
package requirement, is to allow any 3rd party
implementation's runtime libs to be able to be used,
instead of hard coding deps on Mesa supplied libs.

In order to avoid rpm warning about missing libGL and/or
libGLU dependancies, all

Once these new changes are built into rawhide, 3rd party
libGL implementations might choose to add virtual provides
to their subpackages that provide the libGL and/or libGLU
runtimes.  Doing this may reduce the likelyhood of users
experiencing new rpm warnings about missing libGL and/or
libGLU dependancies if they do not already see similar
warnings.

With these new provides/requires in place, any software
which links to libGL or libGLU, can simply do:

BuildRequires: libGL >= 1

and/or

BuildRequires: libGLU >= 1

... and their dependancies will be met correctly, as long
as they have libGL{,U} implementations installed via rpm
packaging which provide the correct virtual provides as
outlined above.  This also should help minimal buildroot
setups to ensure all dependancies get installed.


Future heads up for planning:
This is phase one of several longer term phases we will
be making to X and libGL/libGLU packaging to make life
easier on developers and package maintainers.

The next major change wont occur until the modularized
X11R7 is released.  Once that occurs, we will be shifting
to much more modularized X11 packaging, and will likely
be shipping Mesa and libGLU from their own separate
src.rpm packages.  When that occurs, each library will
have it's own separate -devel subpackage, which will
likely be an even more optimal solution.

As always, during each phase of change, every effort
will be made to try to preserve as much backward
compatibility with existing packaging as possible.  If
we need to make changes that may require 3rd party
packaging changes, we try to minimize the impact of the
changes within reasonable limits, and provide details
far enough in advance for packagers to plan and roll
out updated packages.

If you are a packager of 3rd party libGL/libGLU
implementations, please consider adding the changes
I've recommended above at your earliest convenience.

Thanks in advance.