Re: Multiarch file overlap summary and proposal
David Kalnischkies <kalnischkies@gmail.com> writes:
> On Thu, Feb 16, 2012 at 00:39, Russ Allbery <rra@debian.org> wrote:
>> 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".
Ah, hm... I suppose that's a good point, although honestly I wouldn't mind
having apt-get remove libfoo remove all instances of libfoo that are
installed. I think that would be quite reasonable behavior, and don't
find it particularly unintuitive.
I agree that it's asymmetric. apt-get install libfoo means libfoo:native,
but apt-get remove libfoo means libfoo:*. And asymmetric is bad, all
things being equal. But I think this may be one place where asymmetric is
still the right thing to do; I would argue that it means you're
implementing the most common operation in both cases. apt-get install
libfoo generally means "give me a native libfoo" since non-native libfoo
is going to be an unusual case, and apt-get remove libfoo generally means
"I have no more interest in libfoo, make it go away." I think that people
who want to get rid of one architecture of libfoo but keep the other are
already going to be thinking about architectures, and it's natural to ask
them to qualify their request.
If removing the non-native architecture has cascading effects, apt is
obviously going to warn them about that already and they'll realize what's
going on.
> You can counter this with: Then be specific while installing,
No, I agree that preserving apt-get install libfoo as "install a native
libfoo" is important.
> 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])
Yes, one drawback of my approach is that you use that very simple rule.
> (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. ;) )
Yes, definitely the internals of our package management software can't
fully compress the packages together; at the least, the dependencies are
going to be different between architectures and have to be stored
separately. And I think we're going to want binNMUs in the long run as
well; they're just too helpful for library transitions.
But I think what we should be telling the *user*, regardless of our
internals, is "don't think of libfoo:i386 and libfoo:amd64 as two separate
packages that you can maintain independently; think of libfoo as being
installed for one or more architectures."
> 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.
I think that the best long-term way to handle binNMUs may be to move the
build number into a different piece of package metadata from the version.
So a binNMU of a package with version 1.4-1 would still have version 1.4-1
but would have a build number of 2 instead of 1. I think this would be
way cleaner in the long run, and not just for multiarch.
A lot of stuff would have to change to get to there from here, though.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: