Ian Jackson <ijack...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehtv650n....@windlord.stanford.edu
