Bug 125496 - Add Provides: libGL-devel
Summary: Add Provides: libGL-devel
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: XFree86
Version: 1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks: FC3Target
TreeView+ depends on / blocked
 
Reported: 2004-06-08 05:04 UTC by Ralf Corsepius
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-09-23 16:25:02 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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"


Note You need to log in before you can comment on or make changes to this bug.