Note that the build servers also run into this problem (some -bad plugin screws up in plugin init -> unit tests in good/base/wherever fail, which is just not very useful).

Doesn't this fail spectacularly if people pass --with-package-name='Fedora GStreamer packages' to configure?

I'd rather whitelist based on a variable that cannot be modified by configure options. Unfortunately, I cannot come up with anything but the element or plugin name. And that might make the list a bit long for some tests I suppose?

> Doesn't this fail spectacularly if people pass --with-package-name='Fedora
> GStreamer packages' to configure?
> 
> I'd rather whitelist based on a variable that cannot be modified by configure
> options. Unfortunately, I cannot come up with anything but the element or
> plugin name. And that might make the list a bit long for some tests I suppose?

Right, this is just me being confused. I should be checking GstPluginDesc::source (which contains the autotools-set PACKAGE), not GstPluginDesc::package (which contains the free-form package name).

Created attachment 162094 [details] [review]
pluginloading: add support for whitelisting based on package name and path (2nd patch)

Second attempt: same as above, but check the autotools-set source package identifier rather than the configurable free-form package name.

Committed something along these lines, but allowing plugin-names too:

commit 3410d665d74609802818ef734439b4414a6943b9
Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
Date:   Wed Jun 23 11:02:16 2010 +0100

    binaryregistry: ignore the plugin cache if the filter environment has changed
    
    Make sure that we properly update the registry and the cache file whenever
    the filter environment changes or there's no more filter set.

commit 9c6b87510e854c39b4a4e53e21325bb7ce5b6693
Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
Date:   Thu May 27 12:36:10 2010 +0100

    pluginloading: add support for whitelisting based on plugin or source module name and path
    
    This feature is primarily intended for use in plugin modules' unit tests.
    
    Consider the following situation: gst-plugins-good is built against an
    installed GStreamer core. An older version of gst-plugins-good is also
    installed in that prefix, along with random other plugin modules. Now,
    when doing 'make check' in the just-built gst-plugins-good tree, we
    want to only load plugins from GStreamer core, gst-plugins-base, and
    gst-plugins-good, but not random other modules (we don't want any unit
    tests to fail just because some module in gst-plugins-bad has a broken
    plugin_init, for example). Also, we want to only load gst-plugins-good
    modules from the locally-built source tree, but not any of the older
    gst-plugins-good modules installed. This is usually assured by loading
    the ones in the source tree first (by adding that path first to the
    right environment variables), but it gets tricky when plugins are
    moved, removed, merged, or renamed, or the plugin filename changes.
    
    Note that 'make check' should really work right without doing
    'make install' or uninstalling the old gst-plugins-good package (or
    any other gst-plugins-foo package) first.
    
    Enter GST_PLUGIN_LOADING_WHITELIST. This environment variable may
    contain source-package@path-prefix pairs separated by the platform
    search path separator (G_SEARCHPATH_SEPARATOR_S). The source package
    and path prefix are separated by the '@' character. The path prefix is
    entirely optional, as is the '@' separator if no path is given.
    
    It is also possible to filter based on plugin names instead of the name
    of the source-package by specifying one or more plugin names separated
    by commas before the optional path prefix.
    
    In short, the following match patterns are possible:
    
       plugin1,plugin2@pathprefix or
       plugin1,plugin2@* or just
       plugin1,plugin2 or
       source-package@pathprefix or
       source-package@* or just
       source-package
    
    So for our gst-plugins-good unit test example above, we  would set the
    environment variable on *nix to something like this (will likely be a
    relative path in practice):
    gstreamer:gst-plugins-base:gst-plugins-good@/path/to/src/gst-plugins-good
    
    Fixes #619815 and #619717.