On Sat, Jun 25, 2016 at 02:01:27AM -0700, Josh Triplett wrote: > Sven Joachim wrote: > > On 2016-06-24 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. See https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges (and links) for more examples, potential solutions and problems/shortcomings from each of them. So, as usual, what looks like a simple and easy thing is actually a complexity monster eating little kids^W DDs for breakfast. (That isn't to say stop all discussion… this discussion died down and in case we still need a solution it should 'just' be resumed from the last good state rather than from zero) > > > 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. > > > > This is not at all what dpkg does, the Essential flag only means that > > dpkg will not remove the package in question, unless given the > > --force-remove-essential switch. > > It's been a while since I'd set up "dpkg --add-architecture i386" on a new > system, so I'd misremembered. I had thought that doing so (or subsequently > installing an i386 package) would force the installation of Essential packages > for i386 for any package that was "Multi-Arch: same". Apparently not. Nitpick, but there are no essential M-A:same packages (first, because libraries are forbidden from being essential and M-A:same applies mostly only to them and second, a package tends to be essential because it ships an architecture-independent commandline interface – hence most of them are M-A:foreign – so important that noone can be bothered to depend on it). > > > (And when installing the package, dpkg would need to require > > > it for every supported architecture; dpkg could refuse to configure the > > > package if any enabled architecture doesn't have it unpacked.) > > > > One problem here is that dpkg does not even know which packages are > > available. […] Another nitpick, but dpkg does know (to a certain extend). That isn't all to important in the suggested case here as if you would model it as a hard-requirement as suggested here with configure-refusal or later with an automatic deconfiguration the package would need to exist for all architectures anyhow as if you allow it to be not available for one it isn't a hard-requirement anymore, but a magical recommends depending on which sources a user has currently configured (and happend to be successful in downloading). Such a requirement also prevents packages from adding/removing architectures (probably very very uncommon) and makes the interaction all around pretty strange: I add a new architecture via dpkg and instantly ever package manager screams at me that my system is broken. But that is already written in the wiki… > > I think such problems are better solved in apt: apt-get dist-upgrade > > already reinstalls every Essential package, the same way it could ensure > > That sounds quite reasonable to me. The question then becomes how apt It does to you and me perhaps, but apts handling of essentials (which aptitude has copied and extended to prio:required in recent versions) is the source of constant complains. With every magic implemented in apt it should also be considered what that means for all non-src:apt package managers be them libapt-based or not as for better or worse apt(-get) is by far not the only thing dealing with packages. For Multi-Arch itself I managed to hide away most of it behind implicit dependency relations, versioned provides and 'strange' virtual packages for the libapt-based ones which made that transition quite "easy" all things considered, but we can't pretend it will always be that "easy"… Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature