[MPlayer-DOCS] letter to distro mplayer packagers?

Dominik 'Rathann' Mierzejewski dominik at rangers.eu.org
Fri Dec 2 21:06:57 CET 2005

On Friday, 02 December 2005 at 10:08, Christian Marillat wrote:
> Dominik 'Rathann' Mierzejewski <dominik at rangers.eu.org> writes:
> > On Thursday, 01 December 2005 at 23:44, Christian Marillat wrote:
> >> Dominik 'Rathann' Mierzejewski <dominik at rangers.eu.org> writes:
> [...]
> >> Anyway this is my problem to check if nothing is broken before
> >> uploading news packages.
> >
> > I might have missed it, but are they packaged separately? If not, then
> Of course yes.
> > this _should_ be ok, but what's the point of having shared libs if no
> > other binaries are using them? It's best to link them statically.
> For now transcode, xdtv, xjadeo and xvidcap use a shared libavcodec.

You see, that's what I'm talking about. As long as people keep using all
the above packages from you and you make sure they all work, it may be ok.
But the moment someone replaces one of them with a package from different
source, trouble begin. We've had all sorts of reports of weird errors
(both build-time and run-time) due to mismatched libavcodec.

> >> > * sparc and ppc patches: why not submit them to mplayer-dev-eng?
> >> 
> >> Sparc patch doesn't exist. On others patches aren't mine.
> >
> > What can I say to that? Is it possible to contact their authors and
> > tell them to submit these to us?
> Why to not use these diff ?

We will, of course, take a look at them, but this is not the way free
software works, I think. Free software is also about contributing back.
You're free to modify it, but you should return your contributions to the
source (upstream). Searching for patches someone may have applied in their
package means a lot of additional and unnecessary work. After all, you (or
the author of the patch) already know the reason why it was needed, so why
make us discover that reason again when you can simply tell us while
sending the patch?

> [...]
> >> No, because some options depends on the hardware, like v4l, 3dfx or
> >> mga
> >
> > And in most of these cases, I agree. But, there are others: vstream, amr
> > codecs, freetype, fribidi, xinerama, gl, dxr3, smb, live, v4l(2). Their
> > detection depends only on the existence of certain libs and headers, not
> > device files like for fb/directfb, lirc and others.
> I disagree fribidi is disabled by default :
> Checking for fribidi with charsets ... no

You are right, but this is the only one. The rest _is_ autodetected and I
checked them thoroughly.

> amr is disabled by default :
> Checking for amr narrowband ... no  (libavcodec (static) is required by amr_nb, sorry)
> Checking for amr narrowband, fixed point ... no 
> Checking for amr wideband ... no (libavcodec (static) is required by amr_wb, sorry)

No, it's not. It simply requires static libavcodec, which I already said
is the recommended method of linking it (and is the _default_).

> And certainly others.

Not really.

> I don't intent to break what is already working.

This is of course always a good thing.


MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/
"I am Grey. I stand between the candle and the star. We are Grey.
 We stand between the darkness ... and the light."
        -- Delenn in Grey Council in Babylon 5:"Babylon Squared"

More information about the MPlayer-DOCS mailing list