Re: Multiarch interfaces: print foreign arches, pkgname I/O
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/
Reply to: