Bug 1137 - loading plugins with same profile on different archs
Summary: loading plugins with same profile on different archs
Status: RESOLVED FIXED
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Plugins (show other bugs)
Version: 2.8.0
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2007-03-04 13:08 UTC by Andreas Bierfert
Modified: 2012-12-03 01:30 UTC (History)
0 users

See Also:


Attachments
keep plugin names canonical on clawsrc (2.68 KB, patch)
2012-11-19 00:27 UTC, Ricardo Mones
no flags Details | Diff
keep plugin names canonical on clawsrc (2.68 KB, patch)
2012-11-19 00:27 UTC, Ricardo Mones
no flags Details | Diff
keep plugin names canonical on clawsrc (2.68 KB, patch)
2012-11-19 00:27 UTC, Ricardo Mones
no flags Details | Diff
Same than previous with dependencies load issue fixed (2.84 KB, patch)
2012-11-19 14:49 UTC, Ricardo Mones
no flags Details | Diff

Description Andreas Bierfert 2007-03-04 13:08:36 UTC
I myself use claws on both i386 and x86_64 with the same homedir (shared) and thus with the same config. I do not use two instances at the same time. I do it for my own confeniance as well as for checking if my fedora builds of claws work. The problem I have found is this: If I load plugins on one of the archs use claws normally and close it upon reload on the same arch the plugins are loaded as expected but if I open it on the other arch the plugins are not loaded. I suspect this is because on i386 they are in /usr/lib/claws-mail and on x86_64 on /usr/lib64/claws-mail respectivly. Could it be possible to change the plugin locations as a variable of they are loaded from the default location so that they are usable on both archs without reloading them each time you change archs?
Comment 1 Colin Leroy 2007-03-04 13:19:17 UTC
It would be uneasy to do that while maintaining the possibility to load plugins from anywhere... They need the full path for that. Don't really know what to do, but I'll look for a fix.
Comment 2 Andreas Bierfert 2007-03-04 13:50:26 UTC
Thanks. I suppose I could change the default installation path for the plugins so they reside in the same dir on all archs but that is somewhat ugly (and probably prohibited by the fhs rules).
Comment 3 Ricardo Mones 2012-10-24 19:08:44 UTC
Nice to found that this request is basically what I said in this post:  http://lists.claws-mail.org/pipermail/devel/2012-July/000500.html

About the possibility of loading plugins from anywhere, which IMO should be preserved, I think that if the plugin path starts with / (or any drive letter in case of win32 machines) the path can be taken as absolute, and loaded as currently is.

If not, just prepend the ./configure-d plugin dir (which is already used for opening the load dialog) to the name and you have an absolute path to load from a relative on config.
Comment 4 users 2012-11-14 10:17:36 UTC
Changes related to this bug have been committed.
Please check latest CVS and update the bug accordingly.
You can also get the patch from:
http://www.claws-mail.org/tracker/

2012-11-14 [colin]	3.8.1cvs119

	* src/common/plugin.c
		If plugin fails to load from absolute path, try from
		default plugin path. 
		Fixes bug #1137, 'loading plugins with same profile on different archs'
		Fixes bug #2777, 'Installing latest cvs116 package 14 Windows version
		results in wrong paths in clawsrc'
Comment 5 Ricardo Mones 2012-11-18 10:54:29 UTC
Unfortunately this cannot be closed yet, because load of path-less plugins works, but after exiting Claws Mail all plugin paths are rewritten to clawsrc as absolute paths, so on next run they fail again if loaded from a different arch (prefix).

I think plugin paths shouldn't be rewritten, or, if this is unavoidable, the current prefix should be tried to be removed from current path before saving. 

What do you think?
Comment 6 Ricardo Mones 2012-11-19 00:27:27 UTC
Created attachment 1185 [details]
keep plugin names canonical on clawsrc

This patch fixes the plugin path saved to the clawsrc when the plugin was not load from an absolute path. The name is canonicalized on write to the plugin name without any path if it was succesfully loaded from current Claws Mail prefix.
Comment 7 Ricardo Mones 2012-11-19 00:27:28 UTC
Created attachment 1186 [details]
keep plugin names canonical on clawsrc

This patch fixes the plugin path saved to the clawsrc when the plugin was not load from an absolute path. The name is canonicalized on write to the plugin name without any path if it was succesfully loaded from current Claws Mail prefix.
Comment 8 Ricardo Mones 2012-11-19 00:27:29 UTC
Created attachment 1187 [details]
keep plugin names canonical on clawsrc

This patch fixes the plugin path saved to the clawsrc when the plugin was not load from an absolute path. The name is canonicalized on write to the plugin name without any path if it was succesfully loaded from current Claws Mail prefix.
Comment 9 Colin Leroy 2012-11-19 09:19:22 UTC
Hi,

Thanks! Two things: 
- On load, I'd rather have plugin_load() check that filename is absolute first thing, and work with absolute paths instead of relying on the fallback I've put: else, dependancy loading won't work.
- once that's done, I don't see the need for ->in_prefix_dir ?
Comment 10 Ricardo Mones 2012-11-19 14:49:48 UTC
Created attachment 1188 [details]
Same than previous with dependencies load issue fixed

Now plugin dependencies get marked as loaded from prefix (as they are), so they don't become absolute paths when saving, which would fail on next run from different arch/prefix.
Comment 11 Colin Leroy 2012-11-19 15:03:28 UTC
that's still not that :)
I mean if plugin_load() gets a relative gchar *filename (like "pgpmime.so"), with your patch, it will fail to load /usr/local/lib/claws-mail/plugins/pgpmime.deps.

first thing you need to do in plugin_load() is absolutize the filename parameter if it's not.

At save time, you don't need the in_prefix_dir boolean. You just need to know whether the filename (which is now absolute during runtime) is in the standard dir.

I don't know if I'm clear. :)
Comment 12 Ricardo Mones 2012-11-20 09:20:07 UTC
> that's still not that :)
> I mean if plugin_load() gets a relative gchar *filename (like "pgpmime.so"),
> with your patch, it will fail to load
> /usr/local/lib/claws-mail/plugins/pgpmime.deps.

Nope, that works, it's not easy to follow because of recursivity, but it works ;)

> first thing you need to do in plugin_load() is absolutize the filename
> parameter if it's not.
>
> At save time, you don't need the in_prefix_dir boolean. You just need to know
> whether the filename (which is now absolute during runtime) is in the standard
> dir.

Already thought of that, but it brings a side effect: unconditionally removing
prefix on save alters also plugins which may be valid only in one of the archs.

IOW, it would be always trying to migrate config towards a path-less plugin list,
while current patch just left to the user the decision of which plugins are valid
for every prefix/arch (by editing clawsrc and make them path-less) and which ones
not and remain absolute path of each arch/prefix.

> I don't know if I'm clear. :)

You are, but I think the explanation above will make it even clearer :)

Note You need to log in before you can comment on or make changes to this bug.