On Mon, Jul 05, 2004 at 03:40:43AM -0400, Mike A. Harris wrote:
> 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.
>
Is there any implementation neutral 'Provides:'? Even xorg and XFree86 don't
provide a X11-devel. I even think it was discussed when the change to
xorg-x11 occurred.
The current OpenGL implementation used in Fedora is the Mesa one, and
xorg-x11-devel does provide it:
$ rpm -q --provides xorg-x11-devel
xpm-devel
Mesa-devel
XFree86-devel = 4.4.0
xorg-x11-devel = 6.7.0-4
Is there any reason to make libGL a special case? The current situation
could be improved by specifying the Mesa version that is provided, that
should be enough for the GL version.
Regards,
Luciano Rocha
