Red Hat Bugzilla – Bug 193783
Review Request: mesa-mangled - Mangled Mesa graphics libraries for off-screen rendering
Last modified: 2007-11-30 17:11:34 EST
Spec Name or Url: http://www.cora.nwra.com/~orion/fedora/mesa-mangled.spec
SRPM Name or Url:
A Mangled Mesa that provides OSMesa support
The current mesa in FC5 does not provide libOSMesa. This is because upstream
hase made it nearly impossible to provide a libGL that supports both DRI and
OSMesa. See bug #186366 for a little more on the subject.
This library attempts to provide a "mangled" mesa library "libMesaGL" that
support the provided libOSMesa. My main goal with the package is to be able to
add off-screen rendering support to paraview in FC5+.
Not a Review but some comments on SRC package
W: mesa-mangled invalid-license MIT/X11
W: mesa-mangled strange-permission redhat-mesa-target 0755
(In reply to comment #1)
> Not a Review but some comments on SRC package
> rpmlint gives
> W: mesa-mangled invalid-license MIT/X11
Well, this is what the mesa package in core is, not that is an excuse. In fact
it looks more complicated than that:
Mesa Component Licenses
Component Location Primary Author License
Main Mesa code src/mesa/ Brian Paul Mesa (MIT)
Device drivers src/mesa/drivers/* See drivers See drivers
Ext headers include/GL/glext.h SGI SGI Free B
SGI GLU library src/glu/sgi/ SGI SGI Free B
So, perhaps "Distributable" is better? Suggestions anyone?
> W: mesa-mangled strange-permission redhat-mesa-target 0755
These are scripts executed during package build.
from what you describe isnt this just a workaround for upstream code/design
shouldnt this be fixed upstream rather so we have less redundancy?
The #1 way to solve this, is to autotool mesa, and get acceptance of that
into the Mesa3D project. That'd also be a good time to have libGLU and
libGLw split out and autotooled on their own as well. I believe that
Brian Paul would be open to the autotooling of Mesa, so long as someone
stood up as the maintainer of the autotooling, and actually maintained it.
A few people have indicated they might possibly do such a thing at some
point in the future, but I know that those same people have very high
TODO lists, with many more exciting problems to solve, or issues that
are higher in importance/urgency in the grand scheme of things - so it
isn't clear when - if ever Mesa might get autotooled and then have a
semi-sane buildsystem that avoids problems like this request is attempting
Having said that, as long as Mesa is supplied the way it is now, the
correct way to solve this problem is the same way Debian/Ubuntu and other
distributions have solved it. By applying some elbow grease to our
existing mesa rpm package, and coming up with a conditionalized way to
build OSMesa on whatever arch/variant combos we want, in addition to what
already is built.
Fixing the mesa package to always supply libOSMesa is definitely doable,
and is the "correct" way that it should be done. This will be fixed
eventually, when there aren't more pressing issues to attend to, however
in the mean time, if someone feels like spending the time to fix the
mesa package _properly_, by any combination of patches to Mesa and/or
the spec file, etc. - please feel free.
I'm vetoing this package request, because it will conflict with our
own mesa package, and we do not want things like that to happen in
(Just because something isn't necessarily trivial to fix properly, doesn't
mean we should not fix it properly.)