Re: Multi-Arch for plugin packages
On 30/05/13 16:02, John Paul Adrian Glaubitz wrote:
> I am maintaining one of the gkrellm2 plugin packages, namely
> gkrellm2-cpufreq. All of these gkrellm2 plugin packages install their
> plugins into /usr/lib/gkrellm2/plugins, including mine.
This seems appropriate.
> However, I was wondering whether the plugins should actually
> get installed into /usr/lib/${DEB_HOST_MULTIARCH}/gkrellm2/plugins.
You must install plugins to a location in which they will be loaded
correctly. :-)
It's usually fine for plugins to be in a non-multiarch location, because
you can only have one architecture's gkrellm2 installed - so it's OK
that you can't install gkrellm2-cpufreq:i386 and gkrellm2-cpufreq:amd64
at the same time, because only the one matching the architecture of
gkrellm2 would work anyway.
If the maintainer of gkrellm2 has already made it load from both
traditional and multiarch locations, then you may move the plugin to a
multiarch location (with an appropriate versioned dependency), but I
don't see any particular need to do so.
If the maintainer of gkrellm2 wants to make it load from *only* the
multiarch location, then that's a transition (involving a pile of
versioned Depends/Breaks), which they will have to coordinate with
plugin maintainers like you, and with the release team.
> Anyone knows how Multi-Arch is handled for other similar plugin
> packages, other than gkrellm2 plugins?
telepathy-mission-control-5 specifically isn't Multi-Arch, because I
didn't want to do a small transition (Mission Control + Empathy) for no
actual benefit.
The only plugins that do benefit from being Multi-Arch are those that
are loaded by more than one executable: glibc NSS modules, PAM modules,
ALSA plugins, that sort of thing. These usually have enough
reverse-dependencies that it's worth doing a gradual transition, by
having the plugin-loader load from both locations.
S
Reply to: