Re: Multiarch interfaces: print foreign arches, pkgname I/O
On Mon, 2011-12-05 at 09:55:10 +0100, Guillem Jover wrote:
> [ pkgname I/O proposal ]
Ok, after going over the stuff written on the thread here's the
conclusions I take:
* It might make sense to distinguish between the interface among
programs and the user interface. For example cross-grading should
be considered mostly a program interface problem.
* For dpkg purposes there's mainly two notions of input, those for
commands on installed packages (fully known metadata) and those on
commands for packages to be installed (might be unknown, depending
on how current the available db information is, and if the dpkg
command makes use of it). But usually to be installed input is not
an issue as dpkg just handles filenames not pkgnames. The only
exception is the frontend interface --set-selections, although it's
a rather poor one at that and mostly useful for dselect (lack of
archive origin, specific version candidate, architecture, etc).
* Multi-arch enabled frontends should always use arch qualified names
as dpkg input for possibly ambiguous package names, to cleanly support
a distinct native architecture between dpkg and frontend, and make
possible cross-grading. This means that “M-A: same” need to be always
arch-qualified on input to dpkg. Non “M-A: same” foreign arch
packages do not need to be arch-qualified, as their usage on dpkg
is never ambiguous, there will always be only one installed, but
they could get arch-qualified, that should never be a problem.
* During an upgrade to a multi-arch dpkg using a multi-arch enabled
frontend, the frontend cannot pass over arch-qualified pkgnames
to dpkg. It must verify if it can do so first by checking the
«dpkg --assert-multi-arch» exit code (as per my previous mail).
(Here I've referred to dpkg as a backend, but I'd say in most cases
the same would apply to libapt, or other backends.)
I think this previous list is pretty uncontroversial from what was
discussed on the thread. From that I take the current dpkg output is
almost right, but it seems to differ slightly with apt's output in that
for single instance foreign packages (non M-A: same) it will print them
arch-qualified, to avoid confusing the user for an operation it would
seem strange otherwise (remove + reinstall), although I deem it an
implementation deficiency regarding the unsupported cross-grade case, but
I agree with the underlying issue here. So instead of printing based on
the package being foreign or not, I think it (they src+dst) should be
arch-qualified when an installed instance switches architecture instead.
As the relevant information here is the state change. For dpkg input it
seems clear it should always accept arch-qualified pkgnames.
If we can agree so far, I'll send my other last part regarding pkgname
input.
regards,
guillem
Reply to: