--- Begin Message ---
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 debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20111205085510.GA17383@gaara.hadrons.org
--- End Message ---