Package: apt Severity: wishlist Some packages act as plugins for some other package (the "loader"). To get consistent results, if the plugin is Multi-Arch: same, then it is often desirable for it to be installed for every architecture on which the loader package is installed. I don't think apt has a way for the package maintainer of either the plugin or the loader to request this, but it would be great if it did.
For example, if you install libnss-mdns:amd64 and libnss-gw-name:i386 but not the other way round, then your name resolution will be inconsistent: amd64 programs will be able to resolve foobar.local but not gateway.localhost, and i386 programs will be the other way round. The solution is to install each NSS plugin for both architectures, or for neither. The main use-cases that I can think of: - libc6 is the loader, all NSS modules like libnss-mdns are plugins - libpam0g is the loader, all PAM modules like libpam-cap are plugins - libglx0 is the loader, libglx-mesa0 and libglx-nvidia0 are plugins - libegl1 is the loader, libegl-mesa0 and libegl-nvidia0 are plugins - libvulkan1 is the loader, every package providing vulkan-icd is a plugin I think a Recommends-like level of dependency (selected by default but possible to overrule) would be most appropriate here, which is why this is an apt feature request and not a dpkg feature request. Example: suppose I have an amd64 system with i386 and x32 foreign architectures. If I newly install libc6:i386, and I already have libnss-mdns:amd64 installed, then I would like libnss-mdns:i386 to be recommended for installation. Similarly, if I newly install nvidia-vulkan-icd:amd64, and I already have libvulkan1:amd64, libvulkan1:i386 and libvulkan1:x32 installed, then I would like nvidia-vulkan-icd:i386 to be recommended for installation (but it should not be an error that nvidia-vulkan-icd:x32 doesn't exist). I briefly thought this should be a new Multi-Arch type, "Multi-Arch: every" or something, but on reflection I think that's a bad idea for several reasons: it would require changes to dpkg as well as apt (to treat it as a synonym for "same" for dpkg's purposes) and then waiting one release cycle to deploy the new apt and dpkg; it would try to install the package for all architectures even if the loader is not installed for all architectures, which is unnecessarily eager (for instance if you don't have libvulkan1:i386 installed, then you clearly aren't going to need any i386 Vulkan drivers); and it would be even more confusing than current Multi-Arch. One possible design would be for the plugin to name its loader with something like "Match-Architectures: libvulkan1", meaning: if this package is installed, also install its other multiarch instances on every architecture whose libvulkan1 is installed; and if libvulkan1 is installed for a new architecture, also install the corresponding multiarch instance of each installed package that has "Match-Architectures: libvulkan1". Another possible design would be for the loader to name one or more virtual packages that represent its plugins, with something like "Match-Architectures: vulkan-icd" in libvulkan1 and so on, and the same practical effect but applied from the other end. vulkan-icd, egl-icd and libglx-vendor already exist; there are currently no NSS and PAM equivalents, but the glibc and PAM maintainers could invent a name for this purpose. smcv