> 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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/831768
Title:
aptitude cannot handle conflicts with multiarch enabled
To manage notifications about this bug go to:
https://bugs.launchpad.net/aptitude/+bug/831768/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
