Re: Multi-arch all-architecture plugins
[Ian Jackson]
> If you install on i386 your 2 binaries and libc6, you /do/ need the
> i386 libfakeroot. Otherwise if you say "fakeroot <your binary>" it
> won't work, no matter that /usr/bin/fakeroot is amd64.
libfakeroot is something of a special case, indeed. As a hack to my
proposal, perhaps it can be 'M-A: same-as libc-dev'? I know it's
potentially useful beyond development, but in practice, it seems to be
almost entirely used for development.
> Whereas if you have gimp installed you /either/ have the amd64 or the
> i386 version, and all your gimp plugins need to be the same
> architecture.
[...]
> And indeed the plugin itself need not have a multi-arch field because
> it doesn't need to be coinstalled with other arches.
Right, so gimp plugins aren't really an interesting case.
> > Package: libsasl2-modules
> > Multi-Arch: same-as libsasl2-2
>
> Would it matter if the list of sasl modules installed was different on
> different architectures ? Would that mean that i386 sasl-using
> applications would have different sasl capabilities or would it cause
> libsasl not to start up due to missing plugins ?
The first. It's similar to the PAM modules case. Different apps would
have different capabilities. This doesn't _necessarily_ have security
implications, like getting your PAM modules out of sync, but it's still
something you would not do on purpose, and as such, best if we can
prevent it with infrastructure.
[Bernhard Link]
> Would this also work with nss plugins? That might be a bit more
> complicated as it would be libc6 on most architectures, but libc6.1
> or libc0.1 on others.
True. It would probably need to use a virtual package, like
'glibc-2.13-1'. This might not be a good solution, though, as
apparently the NSS ABI has a wider span than the ABI promised by the
glibc virtual package name. Ideal (for my purposes here) would be if
glibc could provide a virtual package indicating the NSS ABI, akin to
'perlapi-5.10.0'.
Peter
Reply to: