| Summary: | pyglet - A cross-platform windowing and multimedia library for Python | ||
|---|---|---|---|
| Product: | Package Reviews | Reporter: | Orcan Ogetbil <oget.fedora> |
| Component: | Review Request | Assignee: | RPM Fusion Package Review <rpmfusion-package-review> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dtimms, hans, kwizart, rpmfusion-package-review |
| Priority: | P5 | ||
| Version: | Current | ||
| Hardware: | All | ||
| OS: | GNU/Linux | ||
| namespace: | |||
| Bug Depends on: | |||
| Bug Blocks: | 4, 269 | ||
|
Description
Orcan Ogetbil
2008-12-01 09:03:10 CET
Hmm, Has anyone actually taken a look at if it is really impossible to remove the S3TC compression from pyglet? I think S3TC is only usefull on cards which support it, so I would expect pyglet to be able to work without it too. It can be removed. It needs the removal of two files and a simple editing of one file. But it is the primary codec choice of pyglet. From my understanding, the pyglet developers don't care much about the freedom of their software. For instance they also distribute a non-free font in their tarball under a wrong license. My preference is rpmfusion. Today they are using s3tc algorithm. I'm sure tomorrow they'll use something else... We can always drop the package from rpmfusion if someone shows the effort to maintain it in Fedora with those parts removed. I don't have a problem with that. What is your opinion? (this question is to everyone who reads this) Given that pyglet is a library and putting it in rpmfusion, thus means also putting all (potential) applications using this, such as snowballz, into rpmfusion, I vote for putting it in Fedora, but you already sort of knew that. Yes, I understand your concern. But making pyglet Fedora-ready requires more than a few simple tweaks. For instance, one has to write some code to handle the free (and patent-free) audio and video formats. Otherwise, the games using pyglet will be mute. It is doable, but whenever the upstream updates their code, one has to go through everything to make sure nothing gets broken. If you know of someone who will dedicate him-/herself to do all this work in a regular basis, I can assure you that I will not stop him/her. Otherwise, I am insisting on rpmfusion. (In reply to comment #4) > Yes, I understand your concern. But making pyglet Fedora-ready requires more > than a few simple tweaks. For instance, one has to write some code to handle > the free (and patent-free) audio and video formats. Otherwise, the games using > pyglet will be mute. > > It is doable, but whenever the upstream updates their code, one has to go > through everything to make sure nothing gets broken. If you know of someone who > will dedicate him-/herself to do all this work in a regular basis, I can assure > you that I will not stop him/her. Otherwise, I am insisting on rpmfusion. > Well, you could try to get the relevant patches upstream, upstream has said they don't want to do the work to support free formats through other means then avbin, but they are willing to take patches. Anyways I think my opinion on this is clear, but I don't have the time to do this myself, and those doing the work get to decide what the house will look like. So rpmfusion it is. Both sides gave good arguments for their positions. But in the end I tend to say this package is acceptable for RPM Fusion. Sure, it would be better for everyone if the software would get modified to make it acceptable for Fedora. But until someone steps up to do actually do the required work to make that a option let's just ship it here. Or, IOW: It's not our job to fix all of the problems software vendors force on users, linux distributors and RPM package repositories. Is it worth me casting an eye over this review, or will it need a more experienced packager ? I don't think it would be too difficult of a review. Do you have experience with python packages? So there is a problem with the package upstream. Either the package needs the related -devel components for be usable at runtime (even simple apps using pyglet will need them. Or they need to improve the way they dlopen the needed libraries. In other words, the software need to learn how use the right library provided by our linker. Update: Spec URL: http://oget.fedorapeople.org/review/pyglet.spec SRPM URL: http://oget.fedorapeople.org/review/pyglet-1.1.2-4.fc10.src.rpm Changelog 1.1.2-4 - Patch to load the correct (GL*) libraries - Drop mesa-libGL, mesa-libGLU dependencies Here is the explanation of the patch (I also put this in the SPEC file): This patch makes sure that the library loader uses the find_library() facility of ctypes.utils so that the library path is taken from the linker. Normally, pyglet would try to load "libx.so" (which is of -devel type) when the library "x" is called and this would make pyglet fail in certain cases. For instance, when pyglet requests the GL library, it may try to load libGL.so from mesa-libGL-devel, which is not desired. I will submit this upstream asap. Now I have two questions: 1- Should I make pyglet require avbin as it will increase its functionality big time? 2- How shall we handle the libGL dependencies? Is it OK not to put any libGL deps at all? I decided to add avbin,libGL and libGLU deps. Spec URL: http://oget.fedorapeople.org/review/pyglet.spec SRPM URL: http://oget.fedorapeople.org/review/pyglet-1.1.2-5.fc10.src.rpm Changelog 1.1.2-5 - Add Requires: avbin libGL libGLU Okay ------------- This package (pyglet) is APPROVED by me ------------- Package CVS request ====================== Package Name: pyglet Short Description: A cross-platform windowing and multimedia library for Python Owners: oget Branches: F-10 InitialCC: ---------------------- License tag: free (In reply to comment #13) > Package CVS request > ====================== > Package Name: pyglet Done Package imported and built. Closing the bug. Thanks. |