default media player

[Dan Williams]

On Fri, 2005-04-22 at 19:31 +0200, Matthias Saou wrote:
> Hi,
> 
> Just to add a little more to the topic : I'm currently filing a few
> EasyFix bugs for rpmlint found problems against FC Development packages,
> in order to get minor stuff cleaned up before the FC4 test3 freeze. Well,
> I saw that the .mo translations in HelixPlayer weren't colored properly,
> so I started preparing a patch against the latest spec to properly add "%
> lang(xy)" to the %files lines (as i don't know how to use %find_lang with
> more than one translation file base name)... well...
> 
> 1) I've rarely seen such an ugly spec file. For me, the contents are
> clearly the results of bad or broken bits : Manual operations all over the
> place, ugly hacks, many excluded archs... and it doesn't seem easy to
> clean up. 2) The current package doesn't even recompile, as it expects to
> find g++33 which is nowhere to be found in the current distribution (the
> compat is for gcc32 only AFAICT). Packages relying on specific compiler
> versions are plain evil, right? :-)

Unless they break because the current compiler changed, like was the
case with OpenOffice.org for quite a while.  It was using g++33 when the
default compiler became gcc 3.4, because patches for gcc 3.4
compatibility were not available when the decision was made to switch
compilers.  OOo packages still use g++32 on RHEL4, because the version
of the package that's shipped in RHEL4 does not support gcc 3.4 (a
version that _did_ support gcc 3.4 was not available when RHEL4 froze).

The same thing happened with dbus just a couple weeks ago, since the
Pyrex python bindings were generating code that gcc 4 just wouldn't
accept for some reason (which was quite unclear at the time), and until
that was worked out, dbus had to be compiled with compat gcc.

You can't simply switch compilers and expect everything to work right
out of the box.  There are some packages which will take time to patch.

Dan