[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Multi-arch all-architecture plugins

On Tue, Feb 14, 2012 at 22:10, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Aron Xu <happyaron.xu@gmail.com>:
>> On Tue, Feb 14, 2012 at 00:09, Ian Jackson
>> <ijackson@chiark.greenend.org.uk> wrote:
>> > Goswin von Brederlow writes ("Re: Multi-arch all-architecture plugins"):
>> >> As you said these are usualy plugins that nothing depends on. So this
>> >> wouldn't help much. Also if there is a dependency than the rules for
>> >> m-a:same should be sufficient. If the package is something to depend on
>> >> then packages of all architectures should depend on it if they use
>> >> it. The plugin might only be used by amd64 packages and none of the i386
>> >> would depend on it and then installing only amd64 is perfectly fine.
>> This is true for maybe all programs that use alike communication
>> method between main application and its plugins. I encountered another
>> example with D-Bus. The host architecture side listens on a D-Bus
>> session, and "MA: same" plugins installed in other architecture (i386
>> for me) can communicate with the amd64 one and works perfectly fine.
> Goswin and I were talking, I think, about plugins that are loaded with
> dlopen.  These need to be multi-arch:same or something like my
> proposed m-a:all.
> Plugins that interact via fork/exec or dbus or sockets or something
> can be any architecture, even a different architecture to the caller.
> They should be m-a:foreign.  They don't present any difficulty since
> we only need to install one version.

The plugin I mentioned to be M-A:same was not something that enables
the application to use D-Bus interface, but rather something that
would interact with the main program using D-Bus, especially when they
are also a plugin of another M-A: same library at the same time, they
definitely don't belong to M-A: foreign. And the program set up the
D-Bus session should be M-A: foreign.

My description might be still not very clear, here is an example:

We have:
Non-M-A application: fcitx-bin (fcitx)
M-A: same library: libgtk-3-0
M-A: same plugin: fcitx-frontend-gtk3
M-A: foreign plugin: fcitx-module-dbus

 * libgtk-3-0 is the GTK+ 3 library.
 * fcitx-bin  provides some function that some users need.
 * fcitx-frontend-gtk3 is a libgtk-3-0 plugin, which is intended to
behave as a bridge between libgtk-3-0 and fcitx-bin using D-Bus. It is
called using dlopen() by libgtk-3-0.
 * fcitx-module-dbus is a fcitx-bin plugin, which enables fcitx-bin to
use D-Bus. It is call using dlopen() by fcitx-bin.

Given the host architecture is amd64, fcitx-bin:amd64 and
fcitx-module-dbus:amd64 are configured and running on it, the user has
also configured an i386 architecture, which has libgtk-3-0:i386

The point here is when fcitx-frontend-gtk3:amd64 is configured,
fcitx-frontend-gtk3:i386 should be Recommended to be installed and
configured as well. I don't know how this can be achieved in
debian/control by the maintainer.

Aron Xu

Reply to: