Bug 193783
Summary: | Review Request: mesa-mangled - Mangled Mesa graphics libraries for off-screen rendering | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Orion Poplawski <orion> |
Component: | Package Review | Assignee: | 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: | rawhide | CC: | 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
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 (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. 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? 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.) |