GNOME Bugzilla – Bug 513900
[registry] handle inconsistent state if duplicate plugins are removed?
Last modified: 2011-05-19 06:41:43 UTC
+++ This bug was initially created as a clone of Bug #512740 +++ See the above bug for some background. Setting: - core 0.10.17 + gst-plugins-base 0.10.15 installed in /usr - running 'make check' with local -base 0.10.17 build, which will create a local test-registry.xml file. The plugins path of the test environment is specified as LOCAL_PLUGINS:CORE_PLUGINS where core plugins includes the old 0.10.15 -base plugins. Now, later scanned plugin features in the registry will trump earlier ones, so the registry will end up with two plugin records for each duplicate -base plugin, but only one of those (in this case, the installed path) will have the element factories, and the other one will have no element factories. Now, if you uninstall the -base 0.10.15 in /usr and then run 'make check' again, the registry records for those plugins will be removed, along with the element factories. Left in the registry will be empty plugin records for the locally-built plugins without any factories. Timestamp+size will still be up-to-date though, so the registry will not attempt to re-scan those plugins, and as a result those element factories remain invisible/nonexistent. Question is if we want to handle something like this or not. Opinions?
The above analysis isn't really correct (see the original bug), but the issue described may still occur if plugins change name or an element is split out of a plugin into a separate plugin.
I think you fixed that some time ago, the tests should only use the correct plugins now.