[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Multiarch interfaces: print foreign arches, pkgname I/O


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

> 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
</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!

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: