sound problems

[Kevin Kofler]

Paulo Cavalcanti wrote:
> if my memory is not failing, some packages appeared first in ATrpms
> than if Fedora (livna/rpmfusion): xvidcap, xzgv, xv, etc.

But that is pretty much irrelevant. The point is that now those packages are
duplicates and there's no reason to continue providing them in ATrpms, even
if you were first.

> The fedora version of xzgv was never able to display the thumbnails
> correctly, for instance. Why? Because it has to be compiled with gcc3.

Ugh... This is really not a solution, the software should be fixed to work
properly when built with GCC 4 instead.

> But the only reason for the existence of a 3rd party repo is a multimedia
> package. Almost all of them are based on ffmpeg, which is obtained from
> svn. Therefore, it is very difficult to have compatible packages, since
> ffmpeg API changes very often.

And that's why you should let RPM Fusion handle those packages and not waste
your time duplicating them. Again, this is not a matter of who was first,
but practical pragmatism: it makes much more sense to let a big repo like
RPM Fusion with many maintainers do the work (and if you want to help out,
ask for comaintainership within RPM Fusion) than a 2-man show.

I think everyone would benefit from that:
* users, because the repos are no longer incompatible,
* you (both yourself and Axel), because you have less work and get no more
complaints about conflicts,
* RPM Fusion, because they get fewer complaints about conflicts as well, and
if you decide to become comaintainers there, also less work.

And if you want to package something which is not in RPM Fusion, you can
still build it against RPM Fusion's ffmpeg (but it would be better to just
submit it for review in RPM Fusion).

> Because of that, packages like, vlc, mplayer and xine, must get all of
> their dependencies from the same repo.

Kinda my point. ;-) See above.

> As a matter of fact, Fedora supplies a chopped version of xine, and the
> other repos try to "fill the gaps".  They accomplish this by creating
> packages, such as, xine-lib-moles, xine-lib-extras-nonfree,
> xine-lib-extras-freeworld, etc.

Which is the right way to do this. (And FYI, I'm a comaintainer of xine-lib
and xine-lib-extras-freeworld.) Xine-lib has a plugin architecture for a
reason. And FYI, xine-lib-moles and xine-lib-extras-nonfree are obsolete
names (one from FreshRPMs, one from Livna), they're both replaced (with RPM
Obsoletes tags in place) by xine-lib-extras-freeworld from RPM Fusion.

> In xine particular case,  it is much easier to compile it as a whole

It may be easier for you, but it means you're replacing the Fedora package,
potentially causing incompatibilites (and definitely causing file conflicts
with xine-lib-extras-freeworld, which doesn't expect you to ship a xine-lib
which includes this stuff), and also causing repository race conditions
when a new xine-lib comes out (which we may be pushing out very quickly as
a security fix - xine-lib updates are often security-sensitive). (Users
will get the Fedora update and end up without the extra codecs with no
warning.)

> than wasting hours trying to see what is missing.

Then why waste your time when we xine-lib maintainers in Fedora, who are
also the ones maintaining xine-lib-extras-freeworld in RPM Fusion, already
did the work for you?

If you hate RPM Fusion that much, you could just rebuild the
xine-lib-extras-freeworld SRPM from there and ship it. No work for you, and
instant repo compatibility. But I think it would be more helpful for
everyone if you worked with RPM Fusion rather than against it.

> Again, I understand the license issue, but it would be much more
> appropriate if Fedora did not supply it at all (I think a gstreamer
> solution only would be preferable).

No, because many useful apps use xine-lib, especially in KDE:
* The recommended backend for Phonon, which is used for all multimedia in
KDE 4, is the xine-lib backend. There is a GStreamer backend, but it has
many known bugs, especially when used with Amarok 2 (so the Amarok
developers strongly recommend against its use), and its way to handle
output device selection makes it not work with PulseAudio out of the box.
* Several older KDE apps don't support GStreamer at all, for example
Kaffeine (which is still the most powerful KDE video player) and Amarok 1
(which was the app xine-lib was initially introduced for in Fedora).
* Dragon Player (the default video player in KDE 4) requires xine-lib for
some of its functionality (and xine-lib has to be found at build time for
that functionality to be enabled).

> I do not think I am on the dark side of the force, but, from this day on,
> I will avoid posting to any Fedora list.

I think you're overreacting. Please ignore the rudeness some people are
showing and think of cooperating more. While it doesn't really excuse their
rudeness, you have to understand those people are frustrated by the lack of
cooperation from Axel and you over some issues (such as the ones I
highlighted above). I'm sure it is possible to achieve a healthy atmosphere
without you running away.

        Kevin Kofler