[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: libGL and libGLU buildtime dependancy virtualization



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]