On Wed, 2005-06-15 at 12:35 -0500, Jason L Tibbitts III wrote: > I have built a "better" realplayer package; the spec file takes apart > the official package and puts the files in more reasonable spots. It > needs to be updated to the latest version and I made no effort to > limit what content it takes over, but that should all be fixable. > > If you want to have a brief look, the specfile is at > http://www.math.uh.edu/~tibbs/rpms/realplayer/realplayer.spec Two thumbs up, Jason! Well, it's the ${MTYPE} stuff that needs to be tweaked, then realplay.mime, maybe realplay.applications (?) I can see a few things that definitely need to stay: application-ram, application-rm, audio-ra, video-rv I can see a few things that definitely need to go away: *-generic (very nasty and greedy dependencies), audio-mp3, audio-wav But then there's a lot of grey areas. Overall, my opinion is this: 1. Let realplay handle all Real A/V stuff by default. There's no doubt there. 2. Do not let it handle stuff that's handled by popular players that are in the distro already or in the extras - MP3 is already handled by very good media players - for generic AVI stuff there's xine, mplayer, gstreamer, etc. - etc 3. Come up with a good decision regarding the "grey areas" (my hunch: let xine/mplayer/gstreamer handle that too, since they're pretty damn good at that) If I'm not mistaken, what I'm saying is actually equivalent to "let realplay handle stuff that's currently handled by the free Helix player and mark the official Helix package Obsolete by the realplay package" If that's true, then the whole thing might only be a matter of doing copy/paste between the Helix package and the realplay package. There was a short thread on atrpms-users a while ago about this issue: http://lists.atrpms.net/pipermail/atrpms-users/2005-May/thread.html#2938 Also a discussion on the Helix forum: https://helixcommunity.org/forum/forum.php?thread_id=1553&forum_id=6 It looks like there are two options at the moment: 1. Distribute the spec only and let people get the source and build the package themselves (this method is used by some repos to distribute Acrobat Reader) 2. Sign the distribution agreement with Real.com then build and distribute binary packages I would be willing to do even #2, I don't care about signing stuff as long as the conditions are reasonable (they are, in this case, I've been told), but I really have no freakin' time to do this. If you start a discussion some place else (fedora-list doesn't seem the most appropriate place to talk about this issue) please let me know. I'll help with whatever I can. Thank you, -- Florin Andrei http://florin.myip.org/
