Bug 410835

Summary:	FALKON_PLUGIN_PATH is not actually treated as a search path
Product:	[Applications] Falkon	Reporter:	Alexei Robyn <bugs.kde>
Component:	general	Assignee:	David Rosca <nowrep>
Status:	REPORTED ---
Severity:	normal
Priority:	NOR
Version First Reported In:	3.1.0
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Alexei Robyn 2019-08-12 03:19:11 UTC

Contrary to its description in CMakeLists.txt, FALKON_PLUGIN_PATH is not actually treated as a search path of directories to load plugins from, but instead as the single directory to load plugins from (if it is set).

From a brief look through the code, it appears that it is written to account for multiple plugin directories, but that src/lib/app/datapaths.cpp assumes that the environment variable contains a single directory path when reading it, rather than assuming it contains a delimiter-separated list of directory paths.

I would suggest changing it to parse FALKON_PLUGIN_PATH as a list of directories, separated by ':' characters (which would be in line with $PATH, as well as $MOZ_PLUGIN_PATH in Firefox).

Comment 1 David Rosca 2019-08-12 06:53:38 UTC

Why? What is your use case?

Comment 2 Alexei Robyn 2019-08-12 14:36:12 UTC

My intended use is packaging Falkon and third-party plugins separately. I'm looking at improving the packaging of Falkon in nixpkgs to account for third-party plugins, and the Nix approach to packaging stores individual packages in isolated FHS-like subtrees.

Right now I have a kind of meta package that symlinks a set of plugins into a single directory, and wraps falkon to set $FALKON_PLUGIN_PATH to that directory of symlinks. If it were instead treated as a search path, I could just point it directly to the individual plugin directories, which would be preferable.

On non-Nix-based distros, I could also see this being useful for allowing people to use plugins from both system and user sources.