Re: Multiarch file overlap summary and proposal
On Thu, Feb 16, 2012 at 00:39, Russ Allbery <rra@debian.org> wrote:
> 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?
We (as in APT team and dpkg team) had a lot of discussions about that,
see for starters (there a properly more in between the 10 months…)
[0] http://lists.debian.org/debian-dpkg/2011/01/msg00046.html
[1] http://lists.debian.org/debian-dpkg/2011/12/msg00005.html
In short, i think the biggest counter is that it feels unintuitive to
install a library (in native arch) with e.g. "apt-get install libfoo"
while you have to be specific at removal to avoid nuking 'unrelated' packages
with "apt-get remove libfoo".
You can counter this with: Then be specific while installing, but this not
only breaks backward-compatibility (especially dist-upgrades), it also adds
either unnecessary work for single-arch users or it feels strange to accept
a command in singlearch while it fails in multiarch…
(and yes, i know that i have 'lost' the 'battle' in [1], so the handling is
different in APT vs dpkg unfortunately, but that's life it seems…)
Maybe it would help this kind of discussions if we would have a list of
interface changes in dpkg and how someone is supposed to use it in the
future in case this has changed - i personally lost track of that.
(In case someone wants to know this for APT: foo is interpreted as foo:native.
If arch of foo is not native, the packagename is display as foo:arch.
So at least in my eyes brain-death simple - and backward compatible.
[and no, foo:* is currently not supported, but its on the todo])
> 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.
This is the case for M-A:same packages currently.
libfoo:i386 v1 and libfoo:amd64 v2 are not supposed to be co-exist on a
system and as you describe it: its a feature in my eyes, too.
If you want co-installable different versions, call the packages libfoo1 and
libfoo2…
stable/testing users will not have a problem with this version-lock anyway
and unstable users should be able to deal with temporary uninstallable
packages caused by packages not built for all archs yet.
Its not exactly a new type of problem for them anyway…
(btw: doesn't britney do these lock-step upgrades all day long…)
(Note though that e.g. APT is not able to handle installed architectures as an
'attribute'. It not only has to handle them as 'different' packages (and more
specific different versions) to keep backward-compatibility, also different
dependencies on different architectures would make it pretty messy in
practice. But double-think is a requirement for APT development anyway. ;) )
> 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.
Mhh. The current spec just forbids binNMU for M-A:same packages -
the 'sync' happens on the exact binary version.
Somewhere else in this multiarch-discussion was hinted that we could
sync on the version in (optional) Source tag instead to allow binNMU.
It's a bit too late (in my timezone) for me to do serious predictions on
difficult-levels on changing this in APT but i guess its relatively easy.
(the only problem i see is that i don't have ${source:Version} available
currently in the version structure, but we haven't even tried pushing
apt's abibreak to sid specifically as i feared "last-minute" changes…)
The question just remains if it is a good idea…
Best regards
David Kalnischkies
Reply to: