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

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

On Sat, 2011-12-24 at 06:04:46 +0100, Guillem Jover wrote:
> If we can agree so far, I'll send my other last part regarding pkgname
> input.

So, regarding pkgname input:

* The only possible problematic case is related to “M-A: same”
  packages, as multiple instances can be installed or available.

* When using pkgnames as input the cases can be split between, installed
  and available packages. dpkg mainly deals with installed pkgnames
  (as for not-installed it deals with filenames), frontends deal with

* It's always been possible with a non-multiarch enabled dpkg to have
  foreign arch packages installed, even “M-A: same” ones, although
  these both require --force-architecture.

* pkgname (non arch-qualified) has never meant or referred to a native
  package when handling installed packages, it has meant the only single
  possible instance. For available packages it has referred to the
  frontend's native architecture.

* Because both frontend and backend always have knowledge about the
  installed packages, there's never a reason for the frontend not to
  arch-qualify pkgnames for the backend when there might be ambiguity
  (and not doing so brings the problems mentioned previously in the
  thread), except when dpkg is not multiarch enabled, in which case
  there cannot be ambiguity anyway (only a single instance that can
  be installed).

* 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

The remaning solutions from the thread discussed up to now, taking the
above into account are:

* Making pkgname mean always the native arch for “M-A: same” packages,
  but that would make it internally inconsitent (see foreign for
  single-instance package vs native for multiple-instance package), a
  backwards incompatible change to its current meaning for installed
  packages, and would make it possible to make a mess on cross-arch
  support (cross-grade and different arch between frontend/backend,
  maint-scripts, etc).

* Making pkgname mean all installed instances or configured foreign
  arches, this is internally consistent and would be backward compatible,
  it would allow for a smoother upgrade path, but was mentioned in the
  thread could cause user confusion or to end up with lots of cruft
  (on the deity list it was mentioned this was the case on rpm-based
  systems, is there any evidence to back this up?; although as I
  mentioned the user would be presented the proposed solution first,
  and could back off), it's also annoying for the user as they need to
  know beforehand if the package to be installed is “M-A: same”.
  And a minor one, but for dpkg it's annoying regarding --set-selections
  as the selection might be unknown from the available db so we don't
  know if it refers to a wildcard or a single instance.

I still see the second solution to be more correct, although it has
some rough edges on the user side of the interface, and it can be
somewhat cumbersome, so I can see how it's not ideal.

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?


Reply to: