In commit ca000cffbb, we changed to
accept a plugin library name without path. One reason for that
is to keep architecture dependent parts out of the .name file
and possibly support multilib.
However, the shared libraries of VPN plugins are not installed in
a global library search path, but for example into
"/usr/lib64/NetworkManager/libnm-vpn-plugin-openvpn.so".
In that case, specifying "plugin=libnm-vpn-plugin-openvpn.so"
would not be enough to find plugin.
Instead, when configuring a plugin name without path, assume
it is in NMPLUGINDIR directory. Modify nm_vpn_editor_plugin_load_from_file()
to allow path-less plugin-names. Previously such names would be rejected
as not being absolute. This API allows to do file verification
before loading the plugin, but it now supports prepending NMPLUGINDIR
to the plugin name. Basically, this function mangles the plugin_name
argument and checks that such a file exists.
The recently added nm_vpn_editor_plugin_load() continues to behave
as before: it does no checks whatsoever and passes the name directly
to dlopen(). That way, it uses system search paths like LD_LIBRARY_PATH
and performs no checks on the file.
Fixes: ca000cffbb
Contrary to nm_vpn_editor_plugin_load_from_file(), this allows
to specify a library name without path. In this case, g_module_open()
(dlopen()) will search for a library in various system directories.
Split the content of libnm/nm-vpn-editor-plugin.h and
move NMVpnEditorPlugin to libnm-core/nm-vpn-editor-plugin.h.
VPN plugins allow us to extend functionality about VPNs.
This can be also useful for NetworkManager core, hence
move that part to libnm-core.
The name NMVpnEditorPlugin is slightly misleading but not completely
wrong. The "editor" part stands no longer for bringing nm-applet
functionality (alone), but enable general VPN functionality in
the client.
Especially because we already have NMVpnPluginOld with a different
meaning (i.e. a base class of the plugin server implementation).
