View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015028 | Scribus | Plug-ins | public | 2017-10-25 21:41 | 2017-10-26 07:57 |
| Reporter | u ltd. | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | amd64 | OS | alike debian | OS Version | 9 |
| Product Version | 1.5.3 | ||||
| Summary | 0015028: Symlinked plugins are not loaded | ||||
| Description | Under modern Linux and other POSIX systems it is common that configuration files are split and put into subdirectories (so there exists /etc/apt/apt.conf.d/ instead of /etc/apt/apt.conf in my system). Similar, there happens binary sharing / alternative selection with symlinks (/usr/bin/java -> /etc/alternatives/java -> /etc/alternatives/java -> /usr/lib/jvm/java-9-openjdk-amd64/bin/java) As I'm familiar with this symlink technique for system administration / package management, I would expect to be able to use that with scribus, too. But scribus explicitely denies the use of symlinked files (which happend to me when working with plugin files). As I cannot see a reason for this, I propose to change that behaviour. | ||||
| Steps To Reproduce | 1. Compile scribus in a way that it will look for plugins in /usr/local/lib/scribus 2. Create somewhere a directory with the plugins in it which are symlinks by themselfes. 3. ln -s //somewhere/plugins /usr/local/lib/scribus/plugins 4. Start Scribus. 5. Scribus won't find any plugin | ||||
| Additional Information | diff -C 5 old/scribus-1.5.3/scribus/pluginmanager.cpp bug-submission/scribus/pluginmanager.cpp *** old/scribus-1.5.3/scribus/pluginmanager.cpp 2017-05-28 11:10:26.000000000 +0200 --- bug-submission/scribus/pluginmanager.cpp 2017-10-25 23:07:07.000000000 +0200 *************** *** 624,634 **** int PluginManager::platformDllSearchFlags() { #if defined(_WIN32) || defined(_WIN64) return (QDir::Files | QDir::NoSymLinks); #else ! return (QDir::Files | QDir::Executable | QDir::NoSymLinks); #endif } void PluginManager::changeEvent(QEvent *e) { --- 624,634 ---- int PluginManager::platformDllSearchFlags() { #if defined(_WIN32) || defined(_WIN64) return (QDir::Files | QDir::NoSymLinks); #else ! return (QDir::Files | QDir::Executable); #endif } void PluginManager::changeEvent(QEvent *e) { | ||||
| Tags | No tags attached. | ||||
| Patch | Yes | ||||
|
|
Diff with better formatting pluginmanager.cpp.patch (738 bytes)
*** old/scribus-1.5.3/scribus/pluginmanager.cpp 2017-05-28 11:10:26.000000000 +0200
--- bug-submission/scribus/pluginmanager.cpp 2017-10-25 23:07:07.000000000 +0200
***************
*** 624,634 ****
int PluginManager::platformDllSearchFlags()
{
#if defined(_WIN32) || defined(_WIN64)
return (QDir::Files | QDir::NoSymLinks);
#else
! return (QDir::Files | QDir::Executable | QDir::NoSymLinks);
#endif
}
void PluginManager::changeEvent(QEvent *e)
{
--- 624,634 ----
int PluginManager::platformDllSearchFlags()
{
#if defined(_WIN32) || defined(_WIN64)
return (QDir::Files | QDir::NoSymLinks);
#else
! return (QDir::Files | QDir::Executable);
#endif
}
void PluginManager::changeEvent(QEvent *e)
{
|
|
|
why not, but i'm not sure what the interest is, to symlink plugins... since you have to compile and install them from "inside" of scribus... or do you have a workflow allowing a different way of compiling plugins? it might be a good thing as soon as scribus gets real plugins... |
|
|
On my system I introduced an intermediate user which hosts the programs not provided by the package manager. This intermediate user has no system rights, but is write-inaccessible by the running programs of my all-day user -> browser bugs have potentially less impact on my system's security. In contrast to the normal package management, the intermediate user's software is organizes project-wise and finally the binary files are symlinked to a common bin directory which is pointed to by PATH. (similar with libs / shared stuff / config). If I use some custom Scribus version in productive work, I will put it to the intermediate user's space and face the problem again. Another point is that you may provide the scripter API as python2 and python3 version in future and it could be chosen via symlinks (of course it is nicer to be able to configure this from within scribus or even document-wise but this is much harder programming work I guess). |
