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 -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111224050446.ga27...@gaara.hadrons.org
