Re: Multi-arch all-architecture plugins
Peter Samuelson <peter@p12n.org> writes:
> [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.
I don't think it is a special case as such. As Ian says: If you install
any i386 binary then you (potentially) need libfakeroot:i386. And the
common thing for binaries is libc6. Even static binaries depend on the
ld.so from libc6. I think we can ignore the case of libc6:i386 being
installed without any binary needing it.
>> 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.
Except is gimp the only way to use gimp plugins? Isn't there another app
foo that also uses libgimp and its plugins? Then you could have
gimp:amd64, foo:i386.
>> > 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
I think that is unneccessary. Wouldn't the nss plugins already have all
the depends in place to ensure ABI compatibility for the non-multiarch
case? So all we need to add is to get them installed and the existing
depends/conflicts/breaks/... will make sure they are compatible.
So "Multi-Arch: same-as glibc-2.13-1" would be fine. Even "Multi-Arch:
libc" would be fine (if it is provided).
--------------------------[ Summary ]-------------------------------------
I think a few things have become clearer now and we have a few new
ideas.
1) 3 kinds of packages
- plugins stuff depends on (already covered)
- plugins without depends
- LD_PRELOAD libraries
The last two seem to provide identical challenges so lets treat them
the same for now. From now on "plugins" means the later two cases.
2) Plugins are used through some core library. If the core library is
installed for some arch the plugin should be installed for the same
arch. This is not neccessarily all the archs configured in dpkg.
For LD_PRELOAD libraries the libc is a suitable stand-in for the core
library.
Idea: 'same-as core-lib'
3) Admins might want to intentionally not install some plugin for some
arch.
Idea: Something that works like Recommends and not like Depends.
4) Things can be configured to use different plugins on different
architectures. Just because the core library is installed for an
architecture does not always mean the plugin would be used.
It could be nice for the maintainer to specify if this plugin is a
configured-per-arch or always-all-archs case.
Idea: Some flag to switch between Recommends and Suggests semantic?
-------------------------------------------------------------------------
I like both the same-as and the Recommends idea. I don't like the idea
of using the M-A field for same-as. There could be plugins with M-A:same
as well as M-A:allowed semantic (e.g. a plugin enabling some scripting
support like perl for irssi), maybe even M-A:foreign.
I'm not sure if "Recommends: same-as:core-lib" or similar syntax would
be a good idea. It might be best to introduce a new field: "Same-as:
core-lib". This should also be backward compatible in that we do not
need to wait one release cycle before using Same-as.
The behaviour should be that when first installing core-lib for some
arch all the installed plugins are also installed for that arch. But
on upgrade missing plugins are not added.
MfG
Goswin
Reply to: