Hi, On Mon, 05 Dec 2011, Guillem Jover wrote: > So I changed the code in the pu/multiarch/master to only print the > arch qualifier for all “M-A: same” packages, and not for foreign > non-“M-A: same” ones. This makes the output deterministic and consistent > regardless of the native architecture.
Fine for me. It's not the less disruptive approach but you made a good case for it. In general I'm not to worried about dpkg's output changing as long as scripts can extract values on feed them back to dpkg without unpleasant surprises. > One option though if we'd want to preserve output compatibility could be > to only allow co-installability and as such the need to disambiguate > “M-A: same” instances only when a foreign architecture has been configured. I prefer if we stick to the KISS principle so I don't think we want that extra complexity. > One thing that was brought up previously was --get-selections output, > which is not portable in any way to transport the exact state of packages > installed as that depends on the suite, date, architecture, etc. In > addition not all packages are available on other architectures, and > until now foreign packages have not been exposed explicitly. But we > could extend it to give output to ressemble the current selections. I would still suggest to keep the default output as portable as possible. So we would have "libc6 install" by default, and "libc6:<native>" only if some option was added. Foreign packages would obviously get the qualifier because we have no better way to express it. <Thinking out loud> Maybe if we have multiple M-A: same we would output both "libfoo install" and "libfoo:<native> install" to ensure we have the same range of architectures installed when a package is installed for multiple architectures. </Thinking out loud> > 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:*). At least for dpkg --set-selections, I don't agree with this. I would not like to see the command fail because one M-A: same package listed as "libfoo install" is already installed. For the other cases, given the changes in the output of dpkg, I think both are ok. Let's go ahead! 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/20111212091734.ga26...@rivendell.home.ouaza.com
