[Development] The dark side of QtMultimedia

[Thiago Macieira]

On Monday 17 November 2014 20:00:23 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > > > Developers don't care about having the latest version, they care about
> > > > getting work done.
> 
> [snip]
> 
> > I understand, but that only supports my point. So it wasn't the distros
> > that were shortsighted, the upstream developers were.
> 
> But users do care about everything using the latest GStreamer, because it
> means that they don't have to install 2 different versions of the codec
> plugins and that they benefit from the improvements in codec support in the
> maintained GStreamer branch. Not shipping GStreamer 0.10 by default (while
> still having it available in the online repository) also saves a non-
> negligible amount of space on our live images.

I understand that. But applications and frameworks can't switch to a new 
version of GStreamer overnight. Think of how long GStreamer 0.10 has been in 
existence. 

You should also understand that porting code from one version of a dependent 
library to another is low-priority work if it already works with the old 
version. Not only that, it's high risk, so the port needs to be done 
carefully. I'd much rather people kept 0.10 working and in good state than 
rush to 1.0 and introduce bugs and regressions due to incomplete porting.

> Plus, in the GStreamer case, there's also the problem that several things
> drag in GStreamer indirectly through, e.g., QtWebKit or Phonon (the latter
> also being dragged in by some KDE libraries/frameworks), and then if
> QtMultimedia uses a different version, we get symbol conflicts and crashes.
> (And it wouldn't be fair to blame GStreamer for that because Qt does not
> support this situation either and will also crash if you link different
> major versions into the same program.)

QtWebKit is under our control, so we should be able to control whether it 
links to the same version or a different one.

Someone else loading a different version is out of our scope. It's like loading 
Qt4 libraries, we can't do anything about it.

> > By the way, I read somewhere that some distros are considering not
> > shipping Qt 4 as early as their next releases. I also think that's
> > shortsighted. Keep it in your repos all the way into 2017...
> 
> Fedora will not do that. I also consider that a major disservice to those
> distros' users. We still ship even Qt 3 (of course only in the online
> repository) in Fedora. GStreamer 0.10 is also still available, but there are
> practical issues with things using the old version, as explained above. So
> we really want everything ported to the latest version as soon as possible.

Thanks, Kevin.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center