Typically, the packages "claws-mail" and "claws-mail-plugins" are upgraded in sync with eachother. However, in Rawhide it can happen that a newer Claws Mail gets published while the extra plugins fail to build. Then Claws Mail refuses to load the older plugins. As has happened with the upgrade from 3.7.9 to 3.7.10. Should there be a dependency on the Claws Mail version in every plugin package? Or would that be too strict? Is there an interface version that could be read out [in a spec file] and be put into a custom API Provides?
*** Bug 663379 has been marked as a duplicate of this bug. ***
I guess a constraint to the claws-mail major version would be ok. This would leave room for independent rebuilds but avoid this type of conflict. A better solution would be to have a api version in claws which changes only with actual api changes. Maybe this should be an upstream RFE.
Strangely, that's not how their version check works so far. Each plugin hardcodes a minimum version and the version it was compiled with. However, if the Claws Mail version is higher, the plugin is rejected already: src/common/version.h src/common/plugin.c check_plugin_version(): guint32 claws_version = claws_get_version(); [...] if (compiled_claws_version != 0 && claws_version > compiled_claws_version) { [...] if (minimum_claws_version != 0 && claws_version < minimum_claws_version) { [...] claws_get_version() is based on some #define shifting the full version's digits into 32-bit, e.g. MAKE_NUMERIC_VERSION(3,7,10,0) Obviously, "claws_version > compiled_claws_version" is a hard error for any older plugin, so whenever Claws Mail is upgraded, plugins currently need a rebuild. Only if the plugin is built for claws_version 0, this check is skipped, and the minimum_claws_version is checked. The minimum version is something funny. Lots of base plugins currently use this: MAKE_NUMERIC_VERSION(2,9,2,72) For the extra plugins it varies from "2,9,2,72" up to "3,7,8,31".
Ok so what we should do is to add something like Provides: claws-mail(plugin-api) = 3.7.10.0 to the core package and add a script to the devel package to provide this magic number. Then we could use it as a dynamic requirement in the extra plugins package.
Take a look at the claws files. This is a proposal to resolve this issue. http://fedora.lowlatency.de/review/
Adding %{?_isa} to it would avoid the nasty multiarch resolving issues with Yum. And you could add a guard (e.g. in %prep) to verify that the hardcoded %pluginapi matches the actual version.h value. ;)
I'd rather use %{?__isa} within claws-mail(plugin-api-%{?__isa}). I will add a guard! :)
What will happen if %__isa is undefined? Build failure? %_isa would be %nil then and lead to: claws-mail(plugin-api-) = ...
Hm if we can live with the somewhat ugly looking claws-mail(plugin-api(x86-64)) = But I guess considering the %nil part it will look cleaner if %_isa is not available and the extra '-' is avoided.
audacious-libs does Provides: audacious(plugin-api) = ... and in Rawhide: Provides: audacious(plugin-api)%{?_isa} = ... %{?_isa:Provides: audacious(plugin-api) = ...} Surely looks ugly, but that isn't a problem. ;)
> +Requires: claws-mail(plugin-api)%{?_isa} = %(eval "%{_bindir}/claws-mail-plugin-api") > +%{?_isa:Requires: claws-mail(plugin-api) = %(eval "%{_bindir}/claws-mail-plugin-api")} Almost there. The second line is not needed. It would not be arch-specific, btw. The first line does everything that is needed.
Agreed. I was thinking about some backward compat stuff for to long when looking at the audacious stuff.