| Summary: | Add Provides: libGL-devel | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ralf Corsepius <corsepiu> |
| Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
| Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1 | Keywords: | 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: | --- | ||
| Bug Depends On: | |||
| Bug Blocks: | 123268 | ||
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! Everything seems to have worked out ok, closing as "RAWHIDE" |
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