Re: Multiarch file overlap summary and proposal
On Thu, Feb 16, 2012 at 23:10, Carsten Hey <carsten@debian.org> wrote:
> * 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.
:all is already an architecture and currently it seems like dpkg accepts
only that while APT will accept :amd64 (or whatever is native), too,
partly for internal reasons, but also because the difference for an apt-get
user is not really important. Either way, overloading wouldn't be nice.
:any has a special meaning in build-dependencies already meaning - surprise
surprise - give me any package. Overloading would be uncool, beside that
its the wrong word for it anyway if you want all, and not just any package.
>> > 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):
You generously left out the paragraph describing how APT should
detect that the package foo is in fact a library and not, say, a
plugin, a dev-package, a dbg-package or a future-coinstallable binary.
And the foo:* default would be okay and intuitive for all of those?
You also skipped the part of backward-compatibility with tools which
expect a single line/stanza of response and commands like
dpkg --{get,set}-selection which by definition work only with a single
package.
And backward-compatibility means in this context also to support
a dist-upgrade from squeeze to wheezy. If a new version of dpkg
doesn't accept the 'old' commands APT uses the upgrade will
be a pain.
The two threads i mentioned contain a lot more of these
considerations, so it might be in order to read these before
coming up with 'new' ideas.
> * apt-get remove foo removes all installed foo packages (on all
> architectures).
More of a theoretical nitpick, but this was never the case.
apt-get pre-multi-arch handled only packages from native arch (and :all),
so if you had installed foreign packages with dpkg --force-architecture
apt-get would have ignored it, not removed it.
> 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
> <-------------------
Is 'apt-get remove foo+' then going to install all foo's or just one?
The current implementation of always foo == foo:native doesn't fail
your diagram, too, so what is this going to show us?
>> (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.
It's already in for quiet some time ('current' sid amd64, first hit):
Package: 3depict
Source: 3depict (0.0.9-1)
Version: 0.0.9-1+b1
[…]
It's used in other places in APT, e.g. 'apt-get source', which just looks
at the Packages file stanza. That's fine as this isn't a speed critical
operation - but if we want it for the lock-step operation apt needs that
piece of information in its internal structures for fast access to it and
adding new fields in these structures will require an abibreak.
That's the intended meaning of the quoted sentence.
Best regards
David Kalnischkies
Reply to: