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
both.
* 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
pkgname:*.
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?
regards,
guillem
Reply to: