Re: Handling Multi-Arch packages that must be installed for every enabled architecture?
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
Reply to: