[OE-core] Gstreamer packaging

Koen Kooi koen at dominion.thruhere.net
Wed Jun 29 09:33:29 UTC 2011


Saul said I broke gst-meta with my patch, so let's view the gstreamer situation:

given:

1) plugins move between -good, -bad and -ugly
2) libraries move between -good, -bad and -ugly
3) applications require specific plugins
4) upgrade paths must work

When combining 1 and 4 the current 'gst-plugin-{good,bad,ugly}-foo' naming does not work, since the same file will get provided by 2 packages after the move. Attentive readers will have guessed that the current gst-meta tries, and ultimately fails to hide 1) and 2).

So the new systems does the following:

* split out each plugin as gst-plugin-<foo>
* split out each lib as lib<foo>

So both plugins and libraries have a stable package name (barring plugin renames, e.g. flvdemux -> flv). Package feeds and upgrades finally work as expected

There are some downsides with this approach:

a) no way to know a priori where a plugin lives at a given time
b) by extension you build too much or too little.
c) scary multiple provider messages during parsing

OE .dev has a slightly different approach where you manually go through deploy and see what got generated by who and plug that into PROVIDES. I'm not a big fan of that, but it eliminates those scary messages.

I would very much like to have package feeds and upgrades to work, which currently is impossible for gstreamer packages.

regards,

Koen



More information about the Openembedded-core mailing list