realplay RPM is nasty

[Florin Andrei]

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/