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.
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.
> > 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.
I think this demonstrates that my proposal is wrong. The nature of
the dependency ought to be set by the package maintainer.
Ian.
Reply to: