Bug 193783

Summary: Review Request: mesa-mangled - Mangled Mesa graphics libraries for off-screen rendering
Product: [Fedora] Fedora Reporter: Orion Poplawski <orion>
Component: Package ReviewAssignee: Thorsten Leemhuis (ignored mailbox) <bugzilla-sink>
Status: CLOSED WONTFIX QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: mharris, panemade
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://www.cora.nwra.com/~orion/fedora/
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-06-22 22:52:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Orion Poplawski 2006-06-01 15:55:29 UTC
Spec Name or Url: http://www.cora.nwra.com/~orion/fedora/mesa-mangled.spec
SRPM Name or Url:
http://www.cora.nwra.com/~orion/fedora/mesa-mangled-6.4.2-1.fc5.src.rpm
Description: 

A Mangled Mesa that provides OSMesa support

Background:
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+.

Comment 1 Parag AN(पराग) 2006-06-02 04:31:20 UTC
Not a Review but some comments on SRC package
rpmlint gives 
W: mesa-mangled invalid-license MIT/X11
W: mesa-mangled strange-permission redhat-mesa-target 0755


Comment 2 Orion Poplawski 2006-06-02 21:15:56 UTC
(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
                  include/GL/glxext.h

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.



Comment 3 Rudolf Kastl 2006-06-21 09:49:02 UTC
from what you describe isnt this just a workaround for upstream code/design
problems? 
shouldnt this be fixed upstream rather so we have less redundancy?


Comment 4 Mike A. Harris 2006-06-22 22:52:14 UTC
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
to solve.

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
Extras.

(Just because something isn't necessarily trivial to fix properly, doesn't
 mean we should not fix it properly.)