On Sat, Jun 25, 2016 at 09:37:37AM +0200, Ben Hutchings wrote: > On Fri, 2016-06-24 at 23:01 -0700, Josh Triplett wrote: > > Some packages, if installed on any architecture, must be installed for > > every enabled architecture. Most notably, an NSS or PAM module package, > > if enabled in /etc/nsswitch.conf or /etc/pam.d respectively, must exist > > for every enabled architecture to avoid breaking programs for that > > architecture. > > What if I enable an architecture only for cross-building and don't > intend to run programs from that architecture?
How much harm does it do to have (for instance) libnss-foo installed on that architecture? By comparison, how much harm does it do to *not* have libnss-foo installed for an architecture but have it configured in /etc/nsswitch.conf because you have libnss-foo installed for your main system architecture? > > As one possible solution for this problem (but not an ideal one, just a > > thought experiment), dpkg could support a new value for "Multi-Arch", > > "Multi-Arch: every". This value would imply "Multi-Arch: same", but if > > installed, would additionally cause dpkg to act the same way it does for > > Essential packages: install the package when enabling the architecture. > > (And when installing the package, dpkg would need to require installing > > it for every supported architecture; dpkg could refuse to configure the > > package if any enabled architecture doesn't have it unpacked.) > > > > That would solve the problem for the couple of cases it has come up in, > > but it seems far from ideal; I'd welcome an cleaner alternative > > solution. Notably, this doesn't work well for plugin packages for > > libraries less critical than glibc; it's not even ideal for PAM, as not > > every enabled architecture will have packages depending on libpam0g. > > The real dependency is "if any package on the architecture depends on > > package X, and package Y is installed, package Y:arch must be > > installed", but that's excessively complicated. > > I don't think we can ever say there is a hard dependency here. > Instead of adding another Multi-Arch value, how about adding > 'Recommends: Y:every' to Y? (This also moves the problem up from dpkg > to APT.) Recommends doesn't seem like the appropriate dependency relationship for a package required to run programs. Choosing not to install Recommends can produce suboptimal behavior, but "programs fail to run" seems excessive for not installing a Recommends. Y could "Depends: Y:every", though; that would solve the problem, and as you said, raise it from dpkg to apt. Not perfect, as you don't (for instance) need libpam-foo:somearch installed unless you have libpam0g:somearch installed, but better than breaking. Seems like the ideal solution would be (assuming a new virtual package "pam-module" that PAM module packages provided) some dependency field in libpam0g like "Depends: pam-module:same-if-any". That would act like "Depends: pam-module:same-as-libpam0g" if the system had pam-module installed for any architecture. I don't know how much complexity that would introduce, though. - Josh Triplett
