After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 513900 - [registry] handle inconsistent state if duplicate plugins are removed?
[registry] handle inconsistent state if duplicate plugins are removed?
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-02-02 15:46 UTC by Tim-Philipp Müller
Modified: 2011-05-19 06:41 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Tim-Philipp Müller 2008-02-02 15:46:16 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?
Comment 1 Tim-Philipp Müller 2008-02-02 17:32:04 UTC
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.
Comment 2 Sebastian Dröge (slomo) 2011-05-19 06:41:43 UTC
I think you fixed that some time ago, the tests should only use the correct plugins now.