Re: Multiarch interfaces: print foreign arches, pkgname I/O
On Wed, 28 Dec 2011, Guillem Jover wrote:
> So, regarding pkgname input:
[...]
> * An additional cross-arch problem relates to maintainer scripts doing
> for example dpkg -L or -l (or other queries) on “M-A: same” packages,
> because here what's important is either the arch of the package being
> handled (independent from dpkg native arch) or the arch of the package
> being queried (also independent from the native arch), so they need to
> either arch-qualify the package they mean, or pkgname needs to mean
> all installed instances, anything else will cause problems. In
> addition the DPKG_MAINTSCRIPT_ARCH envvar cannot be used because it's
> not related to what's being queried, and --assert-multi-arch might
> not be fully functional when called from maintainer scripts, so
> handling the upgrade case if pkgname means native might prove rather
> tricky as we might not be able to specify neither pkgname:arch nor
> pkgname:*.
>
> The remaning solutions from the thread discussed up to now, taking the
> above into account are:
What about my suggestion in [🔎] 20111213094143.GC22720@rivendell.home.ouaza.com ?
I think it respects all your points. The only limit is that "dpkg -L foo"
might stop working once a second instance of the foo package is installed.
But then that's ok, it just means that some program is not yet
multiarch-aware and ought to be updated.
In some cases, the update will be to use "foo:*" but it might not always
be the right fix so we should not assume it implicitly.
> But I think there's a third option that might satisfy everyone(?), which
> is a mix of the above two:
>
> * Making pkgname mean all instances for installed packages, and only
> the native instance for available packages. This makes the semantics
> fully backward compatible (although internally inconsitent, but that
> was already the case), it avoids the user ending up with cruft. This
> would also make for a smoother upgrade, given that dpkg will only
> handle to be installed packages as filenames and would not make it
> possible to mess up on cross-arch setups. (pkgname:* for available
> packages could mean all configured arches, for installed packages
> it could be an alias to pkgname.)
>
> So how about this? Did I miss anything?
Looks acceptable to me but I don't really agree that it's fully backwards
compatible because anything that ends up meaning multiple packages for
"pkgname" can't be backwards compatible for all programs which are
querying dpkg.
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: