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. (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 -- 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/CAMr=8w662+6o1wx_s-iibkyfezbl3btt7213go7wwwugatd...@mail.gmail.com
