Peter Samuelson <pe...@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 -- 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/878vk4teki.fsf@frosties.localnet