Hi!
I've changed --print-foreign-architectures in pu/multiarch/master to print an entry per line, which makes the print code trivial but more importantly the parsers more natural and simple to write given line based stream input functions, or shell commands reading from a pipe. ---- Package name output and input should be consistent and deterministic, as such restrictions in one should apply to the other. One restriction is related to cross-grading, and while it might seem like a corner-case, not catering for it could cause chaos and a mess on the db when cross-grading dpkg itself. One of the issues with cross-grading is that the native architecture for the running dpkg can be different than the one for the newly unpacked dpkg programs which get invoked during the dpkg run. So any package name I/O that can have a different meaning depending on which architecture is native is not acceptable. Affected are also front-ends having an arch world view calling dpkg multiple times while cross-grading it in one of those. This dicards considering pkgname equivalent to pkgname:native, and to print just pkgname when it can be ambiguous (as in possibly having multiple Multi-Arch: same instances). This last problematic case is when to arch qualify “M-A: same” instances. Qualifiying them only when the arch is foreign introduces confusion, as that depends on which native architecture we are dealing with (c.f. cross-grading). Qualifying them only when there's more than one instance, is also problematic as pkgname then changes meaning depending on the installation or removal order for example. I also don't think it makes sense to qualify non “M-A: same” foreign packages, because there's always only going to be one instance, and for dpkg operations given that there's no ambiguity it does not really matter which one is there (as long as dependencies are fullfilled, etc). Also when cross-grading the output could change. 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. And while it can be argued that this might break backward compatibility, that's only because Debian will be multiarch enabled, the package name output will only switch to be arch qualified on distributions that have had packages marked that way through the field. Others will not get affected. In addition the fact that almost all shared libraries will get arch qualified means we'll be able to detect and fix any script/program not prepared for multiarch pretty quickly, which we have to do anyway. 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. 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. 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:*). regards, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
