Comment 26 for bug 831768

> Is this on track for precise? [April]

TL;DR: as far as upstream is concerned: yes and no. Some larger issues are resolved but unless more help is received there will be many annoyances remaining. Many of the problems are easy to fix but this requires hack-power (i.e. you). Ways in which someone could help:

- consider how commands such as "aptitude search foo" should behave (i.e. show all architectures, only native, foreign-if-installed, …)
- consider how the system in general should treat multiarch packages (consider them a single, or multiple packages? What are the pros and cons of each approach?)
- summarize the remaining multiarch *blockers* (these bug reports are noisy)

For advanced users/developers:
- use and test the current development version (note: git master branch)
- submit patches -- if making design choices (i.e. ignoring foreign-arch packages in CLI search) please explain these when submitting the patch

An upstream release in *Debian* will likely arrive happen during March.

The details…

> I think this bug is fixed in the upstream repo (commit
> e823140847cff74fe97c0a95c727d1a0fe883750)

tbjablin has correctly identified a commit which should have resolved most of the issues involving package states (e.g., being repeatedly considered new, or wrongly installed/not installed). Other recent changes have further improve the general situation but there are still many outstanding problems.

**The current changes are intended only as a stop-gap**

The intention here is to alleviate the problems that many users are experiencing with aptitude on multiarch systems. This may be suitable for release, however, some aspects will likely change in the future. Basically this is the quickest possible way to make the program usable.

**These changes should not yet be considered as "support" for multiarch in aptitude**

To summarise the recent changes:

- foreign-arch packages are arch-qualified ("pkgname:arch") in most places (ala apt-get)
- package states are remembered distinctly for each package:arch combination
- search terms ?architecture and ?multiarch

so, for example, when resolving dependency problems you will now clearly see the architecture of the packages involved and be more informed about what is going on.

The most significant remaining issue is that the dependency/problem resolver has no specific multiarch awareness. This manifests not only in visible garbage[2] but also means that the resolver can not be considered reliable on multiarch systems, in particular, it may or may not act according to the multiarch specification.

The way that APT has implemented multiarch support mitigates this to some extent and the resolver *appears* usable in in some situations (now that architectures are exposed to the user). This is a testament to the great design of those changes in APT. However, I must repeat: the aptitude dependency resolver in it's current (upstream development) form can not be considered correct for multiarch systems.

[2] http://bugs.debian.org/651748

Some command-line actions behave poorly:

$ aptitude search ^emacs23
p emacs23:amd64 - The GNU Emacs editor (with GTK+ user inter
p emacs23-bin-common:amd64 - The GNU Emacs editor's shared, architectur
i A emacs23-common - The GNU Emacs editor's shared, architectur
p emacs23-el - GNU Emacs LISP (.el) files
v emacs23-gtk:amd64 -
v emacs23-gtk -
p emacs23-lucid - The GNU Emacs editor
p emacs23-nox - The GNU Emacs editor (without X support)

emacs23:amd64 is shown but not the native-arch package which is actually installed (!)

Even if the arch-qualifier was omitted from the output it would still be incorrect as the status shown ("p") is for the not-installed amd64 package.

These command-line problems are very easy to fix. Any patches submitted against such issues would be greatly appreciated.