Aron Xu <happyaron...@gmail.com>: > On Tue, Feb 14, 2012 at 00:09, Ian Jackson > <ijack...@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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20282.27454.686027.779...@chiark.greenend.org.uk