Re: Multi-arch all-architecture plugins

[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.

(My example are fcitx-frontend-* and fcitx-module-dbus in Sid.)

> I don't think that's the case.  Consider something like fakeroot.  The
> fakeroot binary itself may be any architecture, because its function
> is to set up a socket and be a server for children and set an
> LD_PRELOAD and so forth.  But the libfakeroot.so must be available for
> all configured architectures so that the LD_PRELOAD works no matter
> what architecture(s') binaries end up running.
>
> So you would have:
>
>   Package: fakeroot
>   Multi-Arch: foreign
>   Depends: libfakeroot
>
>   Package: libfakeroot
>   Multi-Arch: all
>
> and it would have to mean "install libfakeroot for all configured
> architectures".  If libfakeroot were m-a:same then it would mean
> "install libfakeroot for the arch whose fakeroot we picked" which is
> wrong.
>

I second this proposal, but with the doubt about making it a "Depends"
on other co-installed architectures. It might be rather irrelevant on
fakeroot, such an "important" package. But when a user decide to
install something on his primary architecture, and wanted to keep his
other co-installed minimal to do some other stuff, forcing them
installing a bunch of things isn't kind.

Making it works like "Recommends" can be more friendly. And yes, this
way has its shortcomings, but seems to be saner.

-- 
Regards,
Aron Xu