"aptitude install PATTERN" without ~r installs conflicting packages for all architectures

Bug #1050240 reported by Daniel Hartwig on 2012-09-13
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
aptitude
Confirmed
Unknown
aptitude (Ubuntu)
Undecided
Daniel Hartwig

Bug Description

Already reported in Debian; placing here as it impacts all Ubuntu releases which multi-arch support.

[Impact]

Running aptitude install (or remove, etc.) with pattern arguments
selects all architectures and will typically result in conflicts. In
contrast, apt-get only selects a single architecture (the most
preferred) for each package.

Of course, one can insert appropriate ?architecture (~r) terms to
restrict the set, but this is counter-intuitive in the typical
use-case of installing a package for a single architecture only, and
becomes unwieldy with more complex queries.

The default command line behaviour could be adjusted, such that
pattern arguments behaive similar to regex arguments with apt-get.

The apt-get behaviour is most natural. For comparison, consider
the use of search patterns that select versions – the versions are
ignored, only the package is important, and the user must
select the desired version with “=VERSION” or “/ARCHIVE”
(which is also apt-get syntax). See <http://bugs.debian.org/656944>.

[Test Case]

* Enable multi-arch with at least two architectures, then update your package lists.

* Find an uninstalled package, available on multiple architectures, which is preferably Multi-Arch: none or foreign. This bug still applies to Multi-Arch: same packages (it is still unnatural to automatically install both by default) but less severe since they will not conflict.

$ apt-cache policy tf:*
tf:amd64:
  Installed: (none)
  Candidate: 1:4.0s1-17
  Version table:
     1:4.0s1-17 0
        500 http://ftp.iinet.net.au/debian/debian/ sid/main amd64 Packages
        100 /var/lib/dpkg/status
tf:
  Installed: (none)
  Candidate: 1:4.0s1-17
  Version table:
     1:4.0s1-17 0
        500 http://ftp.iinet.net.au/debian/debian/ sid/main i386 Packages

* Install that package using an aptitude search pattern (?exact-name or ?name is good) and observe that both architectures are installed, resulting in conflicts.

$ aptitude install -s '?name(^tf$)'
The following NEW packages will be installed:
  libgpm2:amd64{a} libncurses5:amd64{a} libtinfo5:amd64{a} tf{b}
  tf:amd64{b} zlib1g:amd64{a}
The following packages will be upgraded:
  libncurses5 libtinfo5 zlib1g
The following packages are RECOMMENDED but will NOT be installed:
  libgpm2
3 packages upgraded, 6 newly installed, 0 to remove and 179 not upgraded.
Need to get 1,263 kB/1,523 kB of archives. After unpacking 2,598 kB will be used.
The following packages have unmet dependencies:
 tf:amd64 : Conflicts: tf but 1:4.0s1-17 is to be installed.
 tf : Conflicts: tf:amd64 but 1:4.0s1-17 is to be installed.
 libncursesw5 : Depends: libtinfo5 (= 5.9-6) but 5.9-10 is to be installed.
  C-c C-c

* Compare with apt-get behaviour which selects only the most preferred architecture and therefore does not conflict.

$ apt-get install -s ^tf$
NOTE: This is only a simulation!
      apt-get needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'tf' for regex '^tf$'
The following NEW packages will be installed:
  tf
0 upgraded, 1 newly installed, 0 to remove and 201 not upgraded.

-- Package details:
Package: aptitude
Version: 0.6.6-1

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in aptitude (Ubuntu):
status: New → Confirmed
Changed in aptitude:
status: Unknown → Confirmed
Daniel Hartwig (wigs) on 2013-06-14
Changed in aptitude (Ubuntu):
assignee: nobody → Daniel Hartwig (wigs)
status: Confirmed → In Progress
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.