Bug#536885: symbol lookup error: mplayer: undefined symbol: codec_wav_tags

[Reinhard Tartler]

Reimar Döffinger <Reimar.Doeffinger at gmx.de> writes:

> On Tue, Jul 14, 2009 at 05:38:54PM +0200, Reinhard Tartler wrote:
>> mplayer however contains a private copy of ffmpeg in its sources, and
>> has therefore no problem including headers that are not
>> installed. libavformat/riff.h is e.g. such a header. This is strictly
>> speaking a violation of usage convention, but the mplayer developers
>> don't care here.
>
> Just so that nobody gets the wrong impression: this is not so much not
> careing but that overall due to maintainability issues it still seems
> the better solution so far.
> I admit though that we "focus" more on our users that compile MPlayer
> themselves where this does not pose any issues.
> If this causes too serious issues for distributions we might try to
> re-evaluate, but obviously making us use harder to maintain code needs
> some convincing.

Well, it does cause serious issues on every ffmpeg upgrade when the
mplayer and ffmpeg packages in debian get out of sync. In debian, we
also have to consider partial upgrades, so we need to consider both
packages to be upgraded in any order.

In order to avoid upgrades that affect binary compatibility, we make the
library packages encode the SONAME of the library, so that the both the
old version and the new version can be co-installed. Normally this works
just fine, however ffmpeg is giving us a very hard time for a number of
reasons, and this is just one of several ones (I know about one other
issue, there might be more. need to think about it some more).

I don't want to go into details here right now, because this specific
problem is caused by a broken 3rd party repository. The underlying issue
is more fundamental of course. When I find some more time, I'll try to
put the issues here in a wiki page and bring that up on probably both
the mplayer and ffmpeg developer mailing lists.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4