On Mon, 05 Dec 2011, Guillem Jover wrote: > For package name input, taking into account the output restrictions, > pkgname cannot mean pkgname:native whenever that could be ambiguous > (M-A: same). The only options are then to either consider it pkgname:* > or to fail. I still think pkgname == pkgname:* makes way more sense as > an interface, but failing would also be acceptable to me (as it can > always be switched to pkgname:*).
I was thinking a bit more about this and I don't thinkt that this alternative is the only one. To me it falls down to "be conservative in what you do, but be liberal in what you accept". While it's ok to make sure there's no ambiguity in what we output, it's important to keep backwards compatibility when it comes to what we accept. So "pkgname" should really be accepted and should not represent multiple package instances because it's not what any user unaware of multiarch would expect. It's also not acceptable to fail just because the package is M-A: same because we have such packages installed at the point where a multiarch-enabled dpkg gets installed. So we should only fail when there's a real ambiguity because we have multiple instances installed. In other cases, this should automatically resolve to the single installed instance if any (no matter whether it's foreign or native) or to the native one if there's no installed instance (for example when we do dpkg --set-selections). Does this sound ok? Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- 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/20111213094143.gc22...@rivendell.home.ouaza.com
