Re: Multiarch file overlap summary and proposal
* David Kalnischkies [2012-02-16 03:59 +0100]:
> On Thu, Feb 16, 2012 at 00:39, Russ Allbery <rra@debian.org> wrote:
> >>> it needs to find and remove foo:*
foo:all (or foo:any) instead of foo:* would save the need to quote it.
> > 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".
I would expect this (especially if the package foo is not a library, but
I would also expect this for libraries):
* apt-get install foo tries to install foo:native if possible, if it is
not possible, it tries to install the package foo from an other
architecture but ask before proceeding (as if additional dependencies
are required to install a package).
* apt-get remove foo removes all installed foo packages (on all
architectures).
This summarises how apt without multi-arch handles this, the above would
make apt with multi-arch also behave so:
apt-get install foo
------------------->
foo is not installed foo is installed
apt-get remove foo
<-------------------
> > 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…)
I'm not sure if you meant this with "Source tag", anyway, the 'Packages'
files miss the source version too, but this could be added as optional
field that would be used if it differs from the 'Version:' field.
Regards
Carsten
Reply to: