Rex Dieter wrote:
> - I still say the libGL devel stuff and libGLU should be split
You keep saying that. But, why? There is no other/alternative GL
implementation in Core or Extras (Nvidia's doesn't/shouldn't count in
On the other hand, I thought one of Mike's original motivations for
splitting off Mesa-GL was to allow for drop-in replacements. I'm not
sure if there is value anymore in packaging these separately.
The purpose of splitting out libGL and libGLU was indeed to allow 3rd
party rpm packages to install alternative implementations of libGL
and/or libGLU at the request of a partner. It was a very reasonable
request, and so it got implemented a number of OS releases back.
It is entirely preferred, to have -devel packages for the libraries
shipped in the OS, and to that effect, having -devel packages for libGL
and libGLU is no different. When this was implemented however, -devel
packages did not get created, however that was not an intentional
decision really. It "just happened that way" essentially, and nobody
ever reported any problems, or pointed out the fact that the development
bits weren't also split out, so it stayed that way over time.
Eventually someone did point out the problem, but also pointed out it
wasn't a big deal because it was only a problem if you were using
unsupported 3rd party drivers, and it was pretty easy to work around the
At the time this was discovered in that particular OS development cycle,
it was beyond the freeze date to which additional packages or
subpackages could be added to the OS, and since it was a low impact
issue, which only affected incorrectly installed unsupported 3rd party
drivers, it was definitely not a priority to break our freeze for.
I don't remember which OS release that was exactly, but there have only
been maybe 3 people in 2 years ever even notice the problem and point it
out, so it isn't a major flaw in the OS really, but rather just a minor
inconvenience for some systems with unsupported software installed. The
issue basically fell between the cracks after that, due to the low
number of people reporting the issue and it's relative low priority.
Having given the background now, I do believe the correct solution is to
have separate -devel packages for those libs, for consistency if nothing
else, and we will indeed do this in a future OS release.
Fixing the issue will have some build dependancy problems in the OS and
with some 3rd party rpm packages that do not specify virtual requires
for the libGL and libGLU virtual provides, so fixing this in an erratum,
will not be considered an option. The time to fix this, is in a
development cycle, in which we're updating to a major new release of the
X window system (so we can easily share one src.rpm between multiple
OS's without major ugly hacks to the spec file for one OS release).
When we jump to X11R7, that will be the right time, and there will be
quite a few xorg packaging changes, which make the impact of the change
much smaller also, and so that's when we'll make the change.
Hope this helps.