[Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled

[Daniel Hartwig]

> 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
Foundations Bugs, which is subscribed to aptitude in Ubuntu.
https://bugs.launchpad.net/bugs/831768

Title:
  aptitude cannot handle conflicts with multiarch enabled

Status in aptitude:
  Unknown
Status in “aptitude” package in Ubuntu:
  Triaged
Status in “aptitude” source package in Oneiric:
  Triaged
Status in “aptitude” source package in Precise:
  Triaged
Status in Baltix GNU/Linux:
  New
Status in “aptitude” package in Debian:
  Unknown

Bug description:
  TEST CASE:
  1. Enable multiarch (should be automatic on new oneiric systems)
  2. Install an i386 package on amd64 (like flashplugin-installer:i386)
  3. Mark something with a lot of dependencies for installation
  4. On the confirmation screen, try to remove on of the dependencies (aptitude will now fail to perform upgrades when there's a package conflict w/out removing the i386 libs)

  This renders aptitude painful on a multiarch enabled system (default
  in oneiric).

  ProblemType: Bug
  DistroRelease: Ubuntu 11.10
  Package: aptitude 0.6.4-1ubuntu2
  ProcVersionSignature: Ubuntu 3.0.0-9.12-generic 3.0.3
  Uname: Linux 3.0.0-9-generic x86_64
  Architecture: amd64
  Date: Tue Aug 23 00:28:38 2011
  ProcEnviron:
   PATH=(custom, no user)
   LANG=C
   SHELL=/bin/bash
  SourcePackage: aptitude
  UpgradeStatus: Upgraded to oneiric on 2011-03-06 (169 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/aptitude/+bug/831768/+subscriptions