Bug 111794

>The XFree86-devel package does not have dependencies on the libGL
>and libGLU libraries.

Correct, because it is not dependant on either library.

>This results in broken programs if the packages
>containing the shared libraries, XFree86-Mesa-libGL and
>XFree86-Mesa-libGLU are not installed.

Wrong.  The only way to uninstall those packages, is to force their
uninstallation with --nodeps, which directly tells RPM "I don't
care about dependancies" in which case, you get whatever problems
you create by running such a command.  The breakage in this case
is NOT caused by XFree86 not depending on libGL and libGLU (because
it does NOT actually require them in any way, so it has no business
depending on them artificially), but is caused by improperly
administering package management.

If you uninstall the XFree86-Mesa-libGL and/or XFree86-Mesa-libGLU
packages, in order to have proper RPM managment, you MUST do one of
the following:

- Install an alternative *RPM package* immediately, which properly
  provides libGL and libGLU in the proper locations as determined
  by the OpenGL ABI on Linux standard.  This way, you have
  substituted one RPM managed libGL and/or libGLU library for
  another RPM managed libGL and/or libGLU library, and RPM is happy,
  and dependancies are properly met.

or

- In addition to uninstalling XFree86-Mesa-libGL and
  XFree86-Mesa-libGLU, you must uninstall every single RPM package
  on your system which depends on libGL and libGLU, recursively
  until the entire tree of dependancies on those two libraries is
  removed.

Anything else, is purposeful breakage of the rpm database and rpm
dependancies by the user/admin of the system in question, and
there will indeed be rpm dependancy problems induced by the
user/admin to deal with, until the problems are properly resolved
by installing an rpm managed libGL/libGLU.

>XFree86-devel package includes the headers for libGL and libGLU
>libraries.  It also includes symlinks, /usr/lib/libGL.so and
>/usr/lib/libGLU.so that are used while linking.  If the shared
>libraries aren't installed then the symlinks are broken and linking
>will either fail or produce a binary fails to load.

Correct, and that is intentional.  There are two choices here,
either to make a separate -devel package for libGL and libGLU,
so that non-X OpenGL applications do not need to have an XFree86
development environment installed in order to compile, or to
include the Mesa development symlinks and headers in the
XFree86-devel package.

The latter was chosen because:

1) It is simpler.

2) OpenGL development environments (or any development environment
   for that matter) without XFree86 installed are a very rare
   cookie, and definitely not the general case out there.  Mesa's
   full set of interfaces come _with_ XFree86, and there is not
   any good viable reason to separate out a couple headers and
   symlinks.

As for the symlink itself, it is provided by the system core, in
the XFree86 package intentionally.  The XFree86 package owns that
symlink - but not necessarily the file it points to.  The only
way that the symlink will be broken, is if as I state above, the
user has intentionally forced the removal of the system supplied
libGL and/or libGLU, in which case any breakage caused is entirely
the responsibility of the user to deal with in their customized
unsupported environment.  Replacing the system supplied libGL/libGLU
with an alternative one, which is RPM managed, solves the problem
entirely, except for the symlink.  Simply point the symlink by hand
to the proper location.

>XFree86-Mesa-libGL and XFree86-Mesa-libGLU were split out from
>XFree86-libs recently.  The dependencies for XFree86-devel need to
>have dependencies added for these two packages.

No, they were split out eons ago, and it was done explicitly to allow
3rd party driver vendors to be able to easily replace the system
supplied libGL and libGLU libraries WITHIN RPM CONTEXT.  It was
done at the request of 3rd parties, to make driver installation
and library replacement easier.  Unfortunately, no vendor to my
knowledge has actually taken advantage of this change that was made
for their benefit, so it seems to have turned out to be somewhat
in vain.

Dependancies are not added to packages unless the software actually
REQUIRES them for something.  XFree86-devel does NOT require
Mesa-libGLU or Mesa-libGL at all in any way, and in fact, adding
such a dependancy would defeat the purpose of these subpackages
even _being_ separate.  If XFree86-devel requires them, then
there is no way to have XFree86-devel installed, and be able
to replace Mesa-libGL and/or Mesa-libGLU, and still maintain the
packages properly with RPM.

This is definitely not a bug.  It is a case of system mismanagement.

If you require all of the following:

- To be able to compile OpenGL software
- To be able to replace the system supplied libGL and libGLU with
  alternative 3rd party replacments
- To have an rpm database which is properly managed, and has all
  dependancies for all installed applications and development
  environments installed properly.

Then you _MUST_ do either:

- install your 3rd party libraries using RPM, in which case the
  dependancies should be met properly unless the3rd party rpm
  packages are poorly put together.

or

- Use the system supplied libGL / libGLU

We do not support 3rd party replacment libraries, and we do not
support software not installed via rpm.

Closing bug NOTABUG.

I was wrong that the problem is with libGL.  libGL.so.1 is required by
XFree86-libs and will always be installed when XFree86-devel is installed.

libGLU does not have that dependency.  It is possible to install a
system with XFree86-libs, XFree86-devel, and not have
XFree86-Mesa-libGLU installed.  This is likely to happen with a build
server that is building packages for installation on other machines.

This bug was causing a broken perl-SDL package on the freshrpms.net
repository.  A shared library was not loading because the
/usr/lib/libGLU.so symlink was broken.  I am guessing that the
freshrpms.net build server does not have a graphical environment but
does have the required development packages installed.  Rebuilding the
package on my machine, with a graphical environment and libGLU
installed, worked fine.

I was able to reproduce the broken shared library by removing the
XFree86-Mesa-libGLU package on my machine with --nodeps and producing
an inconsistent system.  I am going to try removing
XFree86-Mesa-libGLU and everything that requires it and build a Fedora
Core package.
  

As I said, using --nodeps, is forcibly breaking the system.  My
claim, is that this problem is impossible to ever occur, without
using --nodeps to install something.  As such, it is not a bug.

*** Bug 111804 has been marked as a duplicate of this bug. ***

As I said above, making the XFree86 package (or the XFree86-devel
package) depend directly upon the XFree86-Mesa-lib* packages defeats
the purpose of those packages being separate at all, as this would
force all users to have both packages installed and no way to remove
or replace them with 3rd party alternatives.  Since the entire point
of the Mesa subpackages is to allow 3rd party placement, it makes
no sense to force XFree86 to require them.  I would obsolete the
Mesa subpackages and put the libs back into XFree86-libs before
adding a dependancy like this, as it would be much simpler, and
it would have the exact same result.  The loss, would be a less
modular system, and the number of people affected by this alleged
problem are extremely small, and it is easy enough to work around.
Our buildsystem for example has no problem with this, which shows
that it is possible to deal with in a clean manner.

The other alternative, as I stated above, is to create an
XFree86-Mesa-devel subpackage, and I would really like to avoid
doing that.  Even if I were to do this however, the fact remains,
that the development symlink provided by our development package
would still point to the Red Hat supplied libGL/libGLU libraries.

As mentioned above, I seriously don't consider this to be a
major problem as-is, however since I am open minded, if there
is enough pressure out there by others that think this is a
large enough problem, I may be able to be convinced to do an 
XFree86-Mesa-devel subpackage anyway as long as it does not
cause further problems.  If I do end up doing that, it will not
be until XFree86 4.4.0 timeframe, so as to avoid additional spec
file complexity by avoiding per-OS-release conditionals.

Your feedback is appreciated.

Oh, one further comment..  if a new -devel package were to be
created, then no Red Hat package should depend on it, or else
it wont be replaceable by a 3rd party either, which would again
defeat the purpose of having it.  That would be theoretically
resolveable by making a virtual provides "libGL-devel" and
"libGLU-devel".

Another problem with this however, is that the new -devel package
itself would then depend on libGLU and libGL together, so
uninstalling only one of them would be difficult.  I suppose more
virtual provides/requires could be instituted, or 2 separate
-devel packages made.

Again though, while this would probably "work", it seems to me
to overcomplicate everything for no major good reason to the end
user, or the masses out there.  I personally do not find it
unreasonable for a development environment to be required
to have a complete XFree86 installation, be it a real OS install,
or a chrootable/vserver type of buildroot.

Again, comments/feedback appreciated.