The Muon Package Management Suite has been getting a lot of attention lately, but this doesn’t mean that cool things aren’t happening elsewhere in the QApt world. Since 1.0, QApt has shipped a utility called QApt Batch, a batch installer used mainly for integrating package installation into KDE applications in Kubuntu. QApt 1.2 will see the inclusion of several more utilities, that have perhaps a bit more… *ahem*… utility than QApt Batch. I will be introducing these new utilities over the next few blog posts as a little blogging miniseries. With that, I’ll start with the first post.
QApt GStreamer Helper
The QApt GStreamer Helper is an implementation of the GStreamer plugin installation framework that GStreamer applications (and more recently the GStreamer Phonon backend now support)
There’s not too much to show. Phonon sends us a request for a plugin, and we ask the user if we can install it.
The searching process uses LibQApt to find packages that provide GStreamer metadata, and uses QtGstreamer to see if the package will provide the needed plugin based on the metadata. I must say, QtGstreamer is a dream to work with. I had originally been using plain ol’ GStreamer to do the matching, and that was torturous for somebody used to nice, C++, object-oriented APIs.
Once packages are found, the QApt GStreamer Helper gives a final confirmation of the items to be installed. The install process uses an interface very similar to QApt Batch.
Finally, the QApt GStreamer Helper has one feature that it offers to those who do not use GStreamer; it is totally optional. LibQApt has no hard dependency against GStreamer for those who wish to not use it. If QtGStreamer is not found at build time, the QApt GStreamer Helper will not be built. This gives QApt more flexibility over PackageKit, since the PackageKit backend itself has to depend against libgstreamer if it is to provide plugin installation services.
The GStreamer helper is in QApt Git master, and will be included along with QApt 1.2.
Jonathan's Blog 
This Amazing.
Thanks for your work.
Will be part of Kubuntu Natty?
Currently Muon/QApt are on a 6-month release cycle, so 1.2 will probably not come out until after Kubuntu 11.04 is released. I am contemplating doing a standalone release of the GStreamer helper before then, though.
The PackageKit yum backend has no GStreamer dependency. Instead, in Fedora, we extract automatic Provides at RPM build time, which look like “Provides: gstreamer0.10(decoder-video/x-h264)” (obviously, that particular codec is provided by third-party-repository packages only, but the autoprov (auto-Provides) extraction also works for those packages). Then, PackageKit only has to ask yum for “gstreamer0.10(“+codecname+”)” and it gets a list of packages providing said codec, no GStreamer involved.
Does this also handle caps variants? For example the decoder-video/mpeg cap is used for decoding mpeg 1, 2 and 4 files, and its full cap is decoder-video/mpeg, mpegversion=(int){ 4, 2, 1 } The PackageKit GStreamer plugin does include these variations in the search string it sends to the PackageKit backends. (In the form of “gstreamer0.10(%s-%s)%s%s”)
To fully satisfy the caps variants, GStreamer’s Caps intersection API would be necessary.
Yes. This is the full list of Provides of gstreamer-plugins-ugly:
gstreamer-a52dec = 0.10.16-2.fc14
gstreamer-dvdread = 0.10.16-2.fc14
gstreamer-lame = 0.10.16-2.fc14
gstreamer-mad = 0.10.16-2.fc14
gstreamer-mpeg2dec = 0.10.16-2.fc14
gstreamer-sid = 0.10.16-2.fc14
gstreamer0.10(decoder-application/vnd.rn-realmedia)
gstreamer0.10(decoder-application/x-pn-realaudio)
gstreamer0.10(decoder-application/x-rdt)
gstreamer0.10(decoder-application/x-rtp)
gstreamer0.10(decoder-audio/AMR)
gstreamer0.10(decoder-audio/AMR-WB)
gstreamer0.10(decoder-audio/ac3)
gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)
gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=1)
gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=2)
gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=3)
gstreamer0.10(decoder-audio/x-ac3)
gstreamer0.10(decoder-audio/x-lpcm)
gstreamer0.10(decoder-audio/x-private1-ac3)
gstreamer0.10(decoder-audio/x-private1-lpcm)
gstreamer0.10(decoder-audio/x-sid)
gstreamer0.10(decoder-video/mpeg)(mpegversion=1)(systemstream=false)
gstreamer0.10(decoder-video/mpeg)(mpegversion=1)(systemstream=true)
gstreamer0.10(decoder-video/mpeg)(mpegversion=2)(systemstream=false)
gstreamer0.10(decoder-video/mpeg)(mpegversion=2)(systemstream=true)
gstreamer0.10(decoder-video/x-ms-asf)
gstreamer0.10(encoder-audio/AMR)
gstreamer0.10(encoder-audio/mpeg)(mpegversion=1)(layer=2)
gstreamer0.10(encoder-audio/mpeg)(mpegversion=1)(layer=3)
gstreamer0.10(encoder-video/x-h264)
gstreamer0.10(urisource-cdda)
gstreamer0.10(urisource-dvd)
gstreamer0.10(urisource-pnm)
libgsta52dec.so
libgstamrnb.so
libgstamrwbdec.so
libgstasf.so
libgstcdio.so
libgstdvdlpcmdec.so
libgstdvdread.so
libgstdvdsub.so
libgstiec958.so
libgstlame.so
libgstmad.so
libgstmpeg2dec.so
libgstmpegaudioparse.so
libgstmpegstream.so
libgstrmdemux.so
libgstsid.so
libgsttwolame.so
libgstx264.so
gstreamer-plugins-ugly = 0.10.16-2.fc14
gstreamer-plugins-ugly(x86-32) = 0.10.16-2.fc14
Ok, so that method would work for yum, but the package names of the virtual provides all contain illegal characters for package names for Debian packages.
Just another example of how PackageKit is really just a package management system designed for Yum without any thought for other packaging systems.
Those characters are also illegal in RPM package names, but they’re allowed in RPM virtual Provides, and in fact RPM best practices recommend the “namespace(name)” notation for this type of virtual Provides exactly because this cannot be the name of a real package.
I wonder if dpkg couldn’t be made more flexible for names of virtual Provides, too. Failing that, the names could be escaped/encoded/mangled in some way.
I would change the “amarok needs an additional plugin to decode this file” instead to “amarok needs an addition plugin to PLAY this file”. using the term decode is geek-speak and not really necessary
[…] This post was mentioned on Twitter by László Torma, Ubuntu World Wide. Ubuntu World Wide said: #ubuntu #linux Jonathan Thomas: Utils, Utils, Utils…: The Muon Package Management Suite has been getting a lot o… http://bit.ly/hc37AD […]
YOU ARE GREAT!