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

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.

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: