Bug 125496

Summary: Add Provides: libGL-devel
Product: [Fedora] Fedora Reporter: Ralf Corsepius <corsepiu>
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 1Keywords: FutureFeature
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-23 16:25:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 123268    

Description Ralf Corsepius 2004-06-08 05:04:11 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031114

Description of problem:
The FC2 xorg-x11-Mesa-libGL-6.7.0-2.i386.rpm package
provides a virtual capability libGL ("Provides: libGL").
Its FC1 counterpart XFree86-Mesa-libGL-4.3.0-42.i386.rpm doesn't.

# rpm -q --provides -p
2/i386/os/Fedora/RPMS/xorg-x11-Mesa-libGL-6.7.0-2.i386.rpm
Mesa
libGL
libGL.so.1
xorg-x11-Mesa-libGL = 6.7.0-2

# rpm -q --provides -p
1/i386/os/Fedora/RPMS/XFree86-Mesa-libGL-4.3.0-42.i386.rpm
Mesa
libGL.so.1
XFree86-Mesa-libGL = 4.3.0-42

This raises compatibility problems with implementing rpm-specs for
GL-based programs, because:
* BuildRequires: XFree86-Mesa-libGL
is only available on systems < FC2.
* BuildRequires: xorg-x11-Mesa-libGL
is only available on systems >= FC2

Using "BuildRequires: libGL.so.1" would work, but would implicitly
restrict building to "version 1" of "libGL.so". Though the version of
libGL is unlikely to change any time soon, this possiblility can not
be ruled out.

The new virtual capability "libGL" would offer a nice, libGL-vendor
and libGL-version independent solution, i.e. Let all libGL based rpms
BuildRequires: libGL

For this to be applicable, FC1's XFree86-Mesa-libGL*rpm would have to
be extended to "Provide: libGL".

Analogous considerations apply to FC1's XFree86-Mesa-libGLU*rpms.
    
Additional info:

This RFE would provide an elegant solution to this issue currently
blocking several libGL/libGLU based package on fedora.us, e.g.
https://bugzilla.fedora.us/show_bug.cgi?id=1680
https://bugzilla.fedora.us/show_bug.cgi?id=1695
https://bugzilla.fedora.us/show_bug.cgi?id=1717

Otherwise, other solutions would have to be considered, e.g. those
currently being discussed in
https://bugzilla.fedora.us/show_bug.cgi?id=1717

Comment 1 Mike A. Harris 2004-07-05 21:38:52 UTC
The virtual libGL provide was actually incorrect and unneeded,
as rpm handles runtime deps.  Applications linking to libGL
should not have any explicit Requires on the package we provide
that contains libGL, as that would make it impossible to substitute
an alternative rpm packages libGL implementation.

A virtual libGL-devel dependancy added in similar nature to what
you describe above however is what we really need, so that OpenGL
application packages can BuildRequire libGL-devel of a particular
libGL version or greater, yet not require a specific implementation
unnecessarily.  If they do require a specific implementation they
can always explicitly require the particular implemenation of course.

I've removed the libGL provide as it shouldn't have really been
there, however I've added a virtual libGL-devel provide recently,
although it is currently considered experimental and is not 100%
committed to yet.  I've posted an email to fedora-devel-list recently
to discuss this topic if you're interested in joining the discussion
also.

I think with the virtual libGL-devel provides we can handle the
build time dependancy reasonably well, in particular when other
libGL packages out there get updated to use it also, and the
runtime dependancy on libGL is already handled by rpm's automatic
dependancy checking.

Similar has been done for libGLU as well.  I'll leave this open
for now until the discussion on the mailing list has concluded and
I've made any necessary changes.

Thanks for your observation and report!

Comment 2 Mike A. Harris 2004-09-23 16:25:02 UTC
Everything seems to have worked out ok, closing as "RAWHIDE"