gstreamer0.10-ffmpeg and how we won't have it for 14.04

Harald Sitter apachelogger at
Tue Mar 25 10:13:01 UTC 2014

On Tue, Mar 25, 2014 at 9:52 AM, Valorie Zimmerman
<valorie.zimmerman at> wrote:
> On Tue, Mar 25, 2014 at 1:29 AM, Harald Sitter <apachelogger at> wrote:
>> General note, since apparently I did not mention this on IRC yet.
>> You *can not*, no, in fact you *must not* have any software that can
>> or could or somehow might use gstreamer1, also can or could or somehow
>> might use gstreamer0.10. Much like Qt4 vs. Qt5 there's symbol clashes
>> at runtime that are going to crash applications in the most obscure
>> and unnecessary fashion.
>> HS
> Do we have a technical way to make it impossible for people to install
> software that will clash with what they already have, whether that be
> gst1, or gst0.10? So if they are installing Application New, that it
> will be reported:
> Installing $AppNew
> Uninstalling $AppOld
> If we have such a technical way, is it possible for us to do that
> before release?

We can't. Not reliably anyway. Take Phonon for example. Applications
do not use gstreamer directly, yet all of them can end up loading
gstreamer at runtime through the phonon backend. On a software level
that is impossible to detect, on a package level the only thing that
even hints at this runtime relationship is that the phonon package
problably recommends the two backend packages.

On top of that in most cases you would not be able to define an atomic
rule to express the conflict potential because you'd have to span the
rule across n relationships (e.g. a depends b depends c depends gst1
AND a depends x depends y depends z depends gst0.10 EQUALS a must not
be installed).

It's why one usually doesn't do a library transition after feature
freeze because someone partially broke the old library...


More information about the kubuntu-devel mailing list