[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

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

Reply to: