Re: Multiarch file overlap summary and proposal
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Joey Hess writes ("Re: Multiarch file overlap summary and proposal"):
>> Here are a few examples of the problems I worry about. I have not
>> verified any of them, and they're clearly biased toward code I am
>> familiar with, which suggests there are many other similar problems.
>> * Puppet not only installs packages, it may remove them. A puppet config
>> that does dpkg --purge foo will fail if multiarch is enabled, now
>> it needs to find and remove foo:*
> Yes.
Actually, why would that be the behavior? Why would dpkg --purge foo not
just remove foo for all architectures for which it's installed, and
require that if you want to remove only a specific architecture you then
use the expanded syntax?
This comes back to something that I started thinking about after Guillem's
message, namely that I think the version lockstep is a feature, not a
limitation. A lot of the complexity from biarch with RPM comes from the
fact that the packages are (as I recall) independent and can be of
different versions. This sounds like a nice feature, but I think it's
actually a huge source of potential confusion and isn't as useful as it
may look.
I think it would be better to have a world in which all the architectures
of the foo package on the system have to have the same version, because
then you don't have to treat foo:i386 and foo:amd64 like they're separate
packages. The list of installed architectures is an *attribute* of the
package. A package is still either installed or not installed, but when
it's installed, it can be installed for one or more architectures. But if
it's installed for multiple architectures, those architectures are always
upgraded together and always remain consistent. That avoids all weirdness
of having a package work differently because the version varies depending
on the ABI, and it significantly simplifies the mental model behind the
package.
Note that this obviously requires that a binNMU not be considered a
different version of the package for this purpose. But I think that too
makes sense. A binNMU *isn't* a full new version of the package; it's a
new build of the same version. We've historically been a bit sloppy about
this distinction, but I think it's a real distinction and a meaningful
one.
I have not looked in detail at the current multiarch implementations and I
have no idea how closely the above matches what is actually being done,
but I would advocate for it, even to the degree of embedding understanding
of binNMU versioning in the package tools so that they know a binNMU is a
new version from the perspective of needing to upgrade the package but not
a new version from the perspective of version mismatches between arches.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: