[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: