aptitude cannot handle conflicts with multiarch enabled

Bug #831768 reported by Micah Gersten
This bug affects 378 people
Affects Status Importance Assigned to Milestone
aptitude
Fix Released
Unknown
Baltix
Invalid
Undecided
Unassigned
aptitude (Debian)
Fix Released
Unknown
aptitude (Ubuntu)
Fix Released
High
Unassigned
Oneiric
Invalid
High
Unassigned
Precise
Fix Released
High
Unassigned

Bug Description

[Impact]

* Inability to use aptitude on multi-arch systems. Any action which results in a packaging conflict, or otherwise broken package, invokes the problem resolver which will proceed to remove *all* foreign-arch packages.

The packages are removed always, even if they are unrelated to the problem being resolved. In the usual case, the problem resolver is unable to find any solution which does not involve removing all foreign-arch packages.

[Fix]

As attached. Update the problem resolver to be more informed about multi-arch packages and specifically the implicit package relations associated
with them.

[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).

*** It has been suggested that this wait longer than 7 days in -proposed for Precise so that it can be extensively tested. ***

[Workaround]
1. If you can survive without 32 bit libraries, just comment out the single line in /etc/dpkg/dpkg.cfg.d/multiarch; or
2. Use another package manager (e.g. apt-get, synaptic, or Software Center)
3. Disable the problem resolver by adding this line in /etc/apt/apt.conf:

Aptitude::ProblemResolver::StepLimit "0";

[Regression Potential]

* Minimal. Patch has received extensive testing in Sid/Wheezy (since September 2012), and Quantal (October 2012). No regressions have been reported.

* Some package relations, particularly conflicts and breaks, may be wrongly ignored and packages not identified as broken by aptitude. This can leave a system in a broken state and/or result in dpkg errors.

* Any complex dependency situation is potentially handled incorrectly.

* Multiple user confirmations that the patch works on aptitude 0.6.6.

[Original Report]
ProblemType: BugDistroRelease: Ubuntu 11.10
Package: aptitude 0.6.4-1ubuntu2
Architecture: amd64

Revision history for this message
Micah Gersten (micahg) wrote :
summary: - aptitude cannot the same packages of diff architectures being installed
+ aptitude cannot handle the same packages of diff architectures being
+ installed
tags: added: multiarch
Micah Gersten (micahg)
summary: - aptitude cannot handle the same packages of diff architectures being
- installed
+ aptitude cannot handle the same packages of different architectures
+ being installed
Changed in aptitude (Ubuntu):
status: New → Confirmed
tags: added: testcase
Micah Gersten (micahg)
description: updated
summary: - aptitude cannot handle the same packages of different architectures
- being installed
+ aptitude cannot handle conflicts with multiarch enabled
description: updated
tags: added: rls-mgr-o-tracking
Changed in aptitude (Ubuntu Oneiric):
importance: Undecided → High
Steve Langasek (vorlon)
Changed in aptitude (Ubuntu Oneiric):
status: Confirmed → Won't Fix
Changed in aptitude (Ubuntu Precise):
status: New → Confirmed
tags: added: rls-mgr-p-tracking
removed: rls-mgr-o-tracking
Revision history for this message
Zorael (zorael) wrote :

Worth mentioning in the known issues section of oneiric release notes?

Steve Langasek (vorlon)
Changed in aptitude (Ubuntu Oneiric):
status: Won't Fix → Triaged
Changed in aptitude (Ubuntu Precise):
status: Confirmed → Triaged
Changed in aptitude (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Jonathan (z3-jonathan) wrote :

After update to oneiric, aptitude gave me strange the option of removing 125 packages.
I had told it to forget the changes then search for broken packages, it picked up qdbus.
With synaptic I installed qdbus and removed qdbus:i386; Back to aptitude and the suggested removals are gone.

Now forget new packages resets after update and 6 unneeded (not recommended) packages get auto selected for install, guessing all down to this bug.

Revision history for this message
Tom Fields (udzelem) wrote :

Definitely must be mentioned in the release notes. Better yet, a popup message on system upgrade when using aptitude.

Revision history for this message
Barosl LEE (barosl) wrote :

I have the similar problem. After upgrading, aptitude tries to remove 123 packages from my system. I can ignore this by Actions - Cancel pending actions. Doing it, I can do normal operations on aptitude, and Search - Find Broken doesn't say anything. It is just normal, though the false alarm occurs again whenever aptitude is turned on.

Revision history for this message
pfaelzerchen (pfaelzerchen) wrote :

Barosl, I recognized something similar after upgrading my notebook. After checking some of the packages I assumed that this may be some 32-bit libraries that are no longer necessary since aptitude said they are installed twice. So I made a backup of the system with rsync to an external hard drive, removed the packages and did a reboot to check if anything starts normal. There were no problems.

3 comments hidden view all 140 comments
Revision history for this message
ruedihofer (ruedihofer) wrote :

Dear all, same problem here. After oneiric upgrade, aptitude shows multiple duplicate entries, one of them being libc6. Both of these libc6 are marked as installed. When I mark one of the entries to be purged, it deletes about 1300 other packeages. When I try the other entry, about 475 packages are deleted.
Regards, Ruedi

1 comments hidden view all 140 comments
Revision history for this message
Ori Avtalion (salty-horse) wrote :

Thanks everyone for confirming the bug. I don't think there's any more need to report it.

If you have any other useful information, please provide it.

Otherwise, please don't turn this bug report into a rant.

This is the first ubuntu release with multiarch enabled, so it's not that far-fetched that there will be problems with non-core tools (such as aptitude, as helpful as it might be).

Shahar, it's very likely that all of the multiarch bugs are due to the same problem, yes.

Steve Langasek (vorlon)
tags: added: rls-p-tracking
1 comments hidden view all 140 comments
Revision history for this message
周成瑞 (e93b5ae3) wrote :

I mostly use aptitude for package managing. I use it daily.
Move /etc/dpkg/dpkg.cfg.d/multiarch to something else can disable multiarch.

Revision history for this message
Bouke Bunnik (bosyber) wrote :

#14 same for me, I'm really considering moving back to natty until this is fixed (also due to some other problems). So what would effect does that workaround have, and what are the side effects?

Revision history for this message
Max Bowsher (maxb) wrote :

No need to move back to natty, if you can survive without 32 bit libraries on oneiric. Just comment out the single line in /etc/dpkg/dpkg.cfg.d/multiarch (as hinted in #14)

Personally I've decided I need aptitude more than I need multiarch.

Revision history for this message
vldmrrr (vldmrrr) wrote :

What if I do need 32 bit libraries -- for example, my brother printer driver requires them. Is there a way to disable multiarch and just install 32 bit support manually?

Steve Langasek (vorlon)
Changed in aptitude (Ubuntu Precise):
milestone: none → ubuntu-12.04
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Brad Figg (brad-figg)
tags: added: bjf-debug
Revision history for this message
Rocko (rockorequin) wrote :

Another example of why you might want 32-bit libraries is that I want to build wine with GL support, but when I try to install the libglu1-mesa-dev:i386 library (from xorg-edgers), apt-get wants to remove over 20 amd64 packages, and I'm not sure how badly it might break my system to go ahead.

1 comments hidden view all 140 comments
Revision history for this message
Colan Schwartz (colan) wrote :

AlexWinner: Rather than adding a comment saying it affect you, please click on the "This bug affects [...]" link at the top. It provides a meaningful metric, and reduces unnecessary clutter in the comments. Thanks.

Revision history for this message
Bert Vorenholt (bert-vorenholt-nl) wrote :

@Max: Thank You for that fine solution! Finally I can use aptitude again.

Steve Langasek (vorlon)
Changed in aptitude (Ubuntu Precise):
importance: Undecided → High
Revision history for this message
Tomáš Hudec (tommy-hudec) wrote :

In multiarchitecture enabled setup the command-line searches also fail to show installed packages correctly. The output of
aptitude search package-pattern
sometimes shows on installed packages that they are NOT installed. I guess that the conflict is in the same package of different architecture being not installed.

Revision history for this message
Hauke (hauke-m) wrote :

The not multiarch capable packages are not required by an multiarch package, but just recommended so just installing this particular package without recommends works.
For installing wine I used the following:

aptitude install --without-recommends libqt4-sql
aptitude install wine
aptitude markauto libqt4-sql:i386

Revision history for this message
Philipp Kern (pkern) wrote :

Is this on track for precise?

Revision history for this message
tbjablin (tjablin) wrote :

I think this bug is fixed in the upstream repo (commit e823140847cff74fe97c0a95c727d1a0fe883750). Is there any chance this could be fixed in time for precise?

Revision history for this message
Daniel Hartwig (wigs) wrote :
Download full text (4.0 KiB)

> 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 em...

Read more...

Revision history for this message
Michal Suchanek (hramrach) wrote : Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled

Hello,

thanks for bringing these fixes.

From my view these are probably enough to make aptitude "support multiarch".

As for resolver being unreliable on multiarch - I don't consider that
a multiarch issue.

It is a long-standing problem that the resolver is generally
unreliable. Any possible multiarch-specific issues will be lost in the
heaps of issues the resolver already has.

The value I see in aptitude is an interactive UI for exploring
packages and their dependencies which should be restored once aptitude
can deal with packages of multiple architectures sanely.

Revision history for this message
Shahar Or (mightyiam) wrote :

Some suggestions:
* aptitude search should show results from all architectures. For filtering of search results by architecture, a new search term should be made (list of serach terms(1))," ?architecture". Short form "~r". Examples: "?architecture(amd64)" and "~ramd64".
 It should show results from all architectures because aptitude's search behavior(2) is very simple: if a package matches all of the terms, it matches the search pattern. So treating the architecture as another search term leverages aptitude's searching mechanism to allow for flexible searching by architecture and also conforms with the expected behavior of aptitude's search.

* Generally, the system should treat multiarch packages as single packages. Mainly because they are. Multiarch packages should have a pseudo-architecture, "all". For example, "apache2-doc:all". This will conform to the filename policy, e.g: "apache2-doc_2.2.22-1ubuntu1_all.deb". This will allow easy and obvious searching in aptitude. For example, "aptitude search ~napache2" would provide all architectures and to filter by architecture One would go, for example, "aptitude search ~napache2~ramd64".
 Treating the multiarch packages as if they were multiple packages would cause confusion. I wouldn't want to even go in to that.

* Aptitude should always default to installing the native architecture when no architecture is specified. This is obvious.

When displaying package names, aptitude should always print their architecture as well, in the format "<name>:<architecture>".

Perhaps there can be a switch in Aptitude that hides packages of foreign architectures when the same name packages exist for the local architecture. With this switch on, Aptitude can also hide the ":<architecture>" part of the names of packages of the local architecture and only display this part for packages of foreign architectures. This would make Aptitude less cluttered. But I would advise against this switch because it could be utterly confusing. Users of Aptitude should be advanced enough to use it's flexible search and interactive mode filtering to display whatever packages / architectures they wish to see.

If multi-arch is disabled system-wide, then Aptitude should still display the full "<name>:<architecture>" format because there may still be foreign architecture packages installed.

There should be a switch in Aptitdue to disable display of the ":<architecture>" part of the format.

1. http://algebraicthunk.net/~dburrows/projects/aptitude/doc/en/ch02s03s05.html
2. http://algebraicthunk.net/~dburrows/projects/aptitude/doc/en/ch02s03.html

1 comments hidden view all 140 comments
Revision history for this message
Daniel Hartwig (wigs) wrote :
Download full text (4.5 KiB)

Thanks for the suggestions.

> [add search term "?architecture(amd64)", "~ramd64"]

This is done (development version). Also there is
'?multiarch(foreign)' etc.

'~r' is a reasonable choice for the short form. I had not
previously assigned one but will do.

> It should show results from all architectures because aptitude's
> search behavior(2) is very simple: if a package matches all of the
> terms, it matches the search pattern.

While this is "technically correct" behaviour, I wonder about it's
utility /on the command-line/. In particular, if a user has
lots of architectures configured (for cross-building or something)
then they will receive many duplicate results:

$ aptitude search pkfoo
i pkfoo
p pkfoo:armel
c pkfoo:mips
p pkfoo:mipsel

I have thought that the generic search (as above, without any
'?terms') should, by default, only return packages for the native arch
*and* any foreign-arch packages that are in some non-trivial state
(installed, config-files, etc.). For most packages, they are
available on every configured arch and the user is implicitly aware of
this. Listing each when they are in the not-present state is just
noise.

If a package is not available on the native arch then the first
foreign-arch version of it will be shown:

$ aptitude search only-for-mips
p only-for-mips:mips

If the user includes an '?archicture(..)' term (or perhaps any term?)
then that would override this behaviour.

Effectively, a search pattern without any '?architecture(..)' term
includes an implicit '?architecture(native-or-next-available)'.

> * Generally, the system should treat multiarch packages as single
> packages. Mainly because they are.

There are subtle differences.

For instance, dependencies vary. Binary packages for hurd-i386, for
example, depend on libc0.3; on freebsd-any they depend on libc0.1;
most other architectures will depend on libc6 *but* the version
required does vary, depending on the architecture.

I am not sure specifically what you mean by "treat multiarch packages
as single packages". Do you mean that, e.g., the interactive mode
of the program should only show each package once? This is possible,
by showing dependencies with arch-qualifiers ala packages.d.o:

  libc0.3 (>= 2.4) [hurd-i386]

There is further complication, that packages may not be updated in
lockstep (i.e. hurd-i386 has version 1.0 while amd64 has 2.0). Then
which should be considered the candidate version for installation?

This *could* be a configurable option, even the default behaviour.
However, it requires larger changes than simply having multi-arch
packages separated by architecture and so I will not be working on
this immediately.

> Multiarch packages should have a pseudo-architecture, "all".

Hi, what?

There is already Architecture: all. I don't understand what you
mean here. Multi-arch packages are of whatever architecture they
are for.

> Treating the multiarch packages as if they were multiple packages
> would cause confusion. I wouldn't want to even go in to that.

Disagree with you here, but then I'm not 100% sure what you meant in
the last two parts so need some clarification.

> * Aptitude should always d...

Read more...

Revision history for this message
Daniel Hartwig (wigs) wrote :

Hi Michal (hramrach)

> Any possible multiarch-specific issues will be lost in the
> heaps of issues the resolver already has.
>

Some do stand out quite harshly. Consider #651748 [1] where the UI
is trashed by multi-arch related error messages from the resolver.
This is non-fatal but still a serious blocker.

I have not encountered it since some recent changes, however,
neither have I conducted an analysis to determine whether or not
it is actually resolved.

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

> The value I see in aptitude is an interactive UI for exploring
> packages and their dependencies which should be restored once aptitude
> can deal with packages of multiple architectures sanely.
>

Then you should be pleased with the changes made thus far :-)

Revision history for this message
Darxus (darxus) wrote :

How to get problems like this added to the Known issues in Release Notes:

I think the biggest crime here is that this has not been added to the Oneric release notes in the last 6 months.

(I HAVE contacted the appropriate person and have been told it will be added on Monday.)

Go to https://wiki.ubuntu.com/ReleaseTeam
Notify the Release Manager of what needs to be added to the Known issues. (Again, I've done this for this bug on Oneric and Precise.)

I really wish I didn't upgrade last night.

Revision history for this message
Darxus (darxus) wrote :

Workaround:

After trying the previously mentioned workaround, things were still broken, complaining about qdbus. So I did:

# If you have disabled multiarch by modifying /etc/dpkg/dpkg.cfg.d/multiarch, you must re-enable it temporarily. The file should exist, and contain the line "foreign-architecture i386" (on my amd64 machine at least).
apt-get update
apt-get install qdbus # will remove qdbus:i386 and install qdbus
# Disable /etc/dpkg/dpkg.cfg.d/multiarch again - add a "#" at the beginning of the line it contains.
aptitude update
aptitude -f install # finally clean
aptitude dist-upgrade # also happy again

So this bug only affects people using 64 bit installs?

I'd still like a better understanding of what my options are if I need to install 64 bit software.

Revision history for this message
Darxus (darxus) wrote :

I decided I don't need aptitude anymore. Thought this info might be useful for others here. Of course, aptitude should still be fixed.

I only used aptitude because I knew if I installed a package, and it automatically installed dependencies, then I uninstalled that package, it would also uninstall its dependencies. When I started using aptitude, apt-get couldn't do that. I basically never use the ncurses interface of aptitude anymore.

It turns out that "apt-get remove" provides that same functionality of removing automatically installed dependencies. Both dependencies that were installed via aptitude, and apt-get. Handling of dependencies installed by aptitude was addded "~4 years ago... when apt started having a notion of autoinstalled packages". - #ubuntu-devel

The devel channel also said that autoremove also works for dependencies installed by all the gui package management software: software-center, update-manager, and synaptic, because they use libapt. So I can stop avoiding using those, which is nice.

You need to use "autoremove" instead of "remove" because apparently somebody thought that was bad default behavior. I'd like something shorter to type than "autoremove".

And, as I guess has been mentioned earlier in this bug, the aptitude resolver is kind of icky.

Here's the evidence autoremove works:

# lsb_release -c
Codename: oneiric

# aptitude install clisp
The following NEW packages will be installed:
  clisp libffcall1{a}
0 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.

# apt-get autoremove clisp
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  clisp libffcall1
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.

# apt-get install clisp
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libffcall1
Suggested packages:
  clisp-doc clisp-dev slime
The following NEW packages will be installed:
  clisp libffcall1
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.

# apt-get autoremove clisp
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  clisp libffcall1
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.

Revision history for this message
Michal Suchanek (hramrach) wrote :

On 10 March 2012 05:49, Daniel Hartwig <email address hidden> wrote:
> Hi Michal (hramrach)
>
>> Any possible multiarch-specific issues will be lost in the
>> heaps of issues the resolver already has.
>>
>
> Some do stand out quite harshly.  Consider #651748 [1] where the UI
> is trashed by multi-arch related error messages from the resolver.
> This is non-fatal but still a serious blocker.

Is this multiarch specific?

IIRC I got this noise way before multiarch, there was just way less
noise before there were packages aptitude does not understand.

Now that aptitude understands multiarch packages you should not get
bazillions of errors.

Sure, it's still potential problem that there is no rate limit on
these messages or anything but it's no longer likely that you will not
see any UI at all due to messages rolling all over your screens
constantly.

Revision history for this message
Daniel Hartwig (wigs) wrote :

>> Some do stand out quite harshly. Consider #651748 [1] where the UI
>> is trashed by multi-arch related error messages from the resolver.
>> This is non-fatal but still a serious blocker.
>
> Is this multiarch specific?
>
> IIRC I got this noise way before multiarch, there was just way less
> noise before there were packages aptitude does not understand.
>

Indeed. Before m-a the messages were very infrequent, one could
consider this a less than serious issue.

After m-a such messages are now frequently encountered when
performing any non-trivial action.

Getting noticeably more garbage on the screen is a problem.

> Now that aptitude understands multiarch packages you should not get
> bazillions of errors.
>

Have you been using the in-development version and noticed less
errors, or is this just speculation?

If you have been using that version, then this is useful information.
Obviously I can know what is happening on my system which is only
a small m-a chroot for the moment--not the most extensive
test setup.

> Sure, it's still potential problem that there is no rate limit on
> these messages or anything but it's no longer likely that you will not
> see any UI at all due to messages rolling all over your screens
> constantly.
>

[The standard C-l works in aptitude to refresh the screen.]

The underlying problem is that these internal debug messages
should not be dumped to stdout while using the curses interface.
They should either direct to a file by default or be captured
using apt-pkg/contrib/error.h like other error messages.

Revision history for this message
Michal Suchanek (hramrach) wrote :

>> Now that aptitude understands multiarch packages you should not get
>> bazillions of errors.
>>
>
> Have you been using the in-development version and noticed less
> errors, or is this just speculation?

No, I don't see the in-development version packaged anywhere. However,
this is more than just speculation. Obviously, many of the errors are
caused by aptitude's inability to tell apart package:i386 and
package:amd64 which should by fixed now.

Revision history for this message
Shahar Or (mightyiam) wrote :
Download full text (7.1 KiB)

On 10 March 2012 06:20, Daniel Hartwig <email address hidden> wrote:
> '~r' is a reasonable choice for the short form.  I had not
> previously assigned one but will do.

Great!

>>  It should show results from all architectures because aptitude's
>> search behavior(2) is very simple: if a package matches all of the
>> terms, it matches the search pattern.
>
> While this is "technically correct" behaviour, I wonder about it's
> utility /on the command-line/.  In particular, if a user has
> lots of architectures configured (for cross-building or something)
> then they will receive many duplicate results:
>
> $ aptitude search pkfoo
> i   pkfoo
> p   pkfoo:armel
> c   pkfoo:mips
> p   pkfoo:mipsel
> …
>
> I have thought that the generic search (as above, without any
> '?terms') should, by default, only return packages for the native arch
> *and* any foreign-arch packages that are in some non-trivial state
> (installed, config-files, etc.).  For most packages, they are
> available on every configured arch and the user is implicitly aware of
> this.  Listing each when they are in the not-present state is just
> noise.
>
> If a package is not available on the native arch then the first
> foreign-arch version of it will be shown:
>
> $ aptitude search only-for-mips
> p   only-for-mips:mips
>
> If the user includes an '?archicture(..)' term (or perhaps any term?)
> then that would override this behaviour.
>
> Effectively, a search pattern without any '?architecture(..)' term
> includes an implicit '?architecture(native-or-next-available)'.

We do want to make the search results as humanly readable as possible
while keeping it obvious to understand.

We should do this by assuming that most users prefer native
architectures and would like to see what's installed, has
configuration files or is broken (these three are the non-trivial
states, right?).

So an aptitude search without ?terms() should print:
1. packages that are available in the native architecture as "<name>"
2. multi-arch packages as "<name>:all"
3. each available architecture of packages that are available only in
foreign architectures as "<name>:<architecture>"
4. foreign architecture packages that are in non-trivial states as
"<name>:<architecture>"

This should be called "?architecture(prefer-native)".

So the difference between this and the
"?architecture(native-or-next-available)" term value is that it would
show all architecture packages and not only the first foreign
architecture package. The reason for this is that the order in which
they are specified in the /etc/dpkg/dpkg.conf.d/multiarch is not an
order of preference.

# so for example
$ dpkg --print-architecture
amd64
$ aptitude search foo
p foobar # no architecture suffix because native
p foo-common:all # multi-arch
p foo-mips:mips # only in foreign architectures...
p foo-mips:mipsel # so printing all of them
p food # same as foobar
i food:i386 # installed and foreign
c food:mips # configuration files present and foreign

This defaulting to an "?architecture(prefer-native)" filter in
command-line search is a preference of convenience over consistency.
To prevent any trouble, whenever a search ...

Read more...

Changed in aptitude:
status: Unknown → Fix Committed
Changed in aptitude (Debian):
status: Unknown → Fix Committed
Revision history for this message
Daniel Hartwig (wigs) wrote :

> 3. each available architecture of packages that are available only in
> foreign architectures as "<name>:<architecture>"

Ok, this may prove more useful than what I was considering (only show the first such architecture).

> The reason for this is that the order in which
> they are specified in the /etc/dpkg/dpkg.conf.d/multiarch is not an
> order of preference.

Dpkg does not care about the order of architectures because it only deals with exactly the packages it is instructed to.

On the APT level a prefered order is needed. APT::Architectures is the configuration item that defines this (/etc/apt/apt.conf or /etc/apt/apt.conf.d/*).

> Dear Daniel, you said "- 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?)"
>
> Can you please elaborate on that question?

Things like, should the package view be grouped by architecture?

--\ Installed Packages
  --\ armel
    --- admin
    ...
  --\ powerpc
    --- admin
    ...

Or should each package only be shown once (just the name) and
have the different available architectures elaborated on the
package info screen?

> Why should multi-arch
> packages be considered multiple packages?

To be clear, when I say 'multi-arch packages' I am refering to packages which implement the multi-arch spec[2] -- not packages which are 'Architecture: all'. I am not sure if you mean the same thing here, since you keep refering to multi-arch packages being displayed as "pkg:all".

The reason they might be considered separate packages is because they are. Anything else is just a (potential) convenience to the user.

foo:armel, foo:powerpc, foo:amd64 are all distinct packages which just happen to share the same name. There are many differences between them that make each unique.

[2] http://wiki.ubuntu.com/MultiarchSpec

>>> Treating the multiarch packages as if they were multiple packages
>>> would cause confusion. I wouldn't want to even go in to that.
>>
>> Disagree with you here, but then I'm not 100% sure what you meant in
>> the last two parts so need some clarification.
>
> I'm also not 100% sure what you meant with that, above.

I meant that I was confused about the last two parts of your post because it seemed like you were refering to "multi-arch packages" as being equivalent to "architecture: all".

The part I disagree with is that treating multi-arch packages as multiple packages would cause confusion.

>> I consider it undesirable for aptitude to deviate from APT on this
>> point. However, having this configurable (e.g. "APT::FullName::Pretty-Print")
>> would be an excellent option.
>
> Yes, this is an excellent idea. As long as Architecture:all packages
> are printed with the ":all" suffix, to differentiate them from the
> native arch packages.
>

"apache-doc:all" would be deviating from APT, which shows "apache-doc".

Also, 'Architecture: all' is always a native architecture.

Revision history for this message
Michal Suchanek (hramrach) wrote :

On 13 March 2012 03:26, Daniel Hartwig <email address hidden> wrote:
>> 3. each available architecture of packages that are available only in
>> foreign architectures as "<name>:<architecture>"
>
> Ok, this may prove more useful than what I was considering (only show
> the first such architecture).
>
>> The reason for this is that the order in which
>> they are specified in the /etc/dpkg/dpkg.conf.d/multiarch is not an
>> order of preference.
>
> Dpkg does not care about the order of architectures because it only
> deals with exactly the packages it is instructed to.
>
> On the APT level a prefered order is needed.  APT::Architectures is the
> configuration item that defines this (/etc/apt/apt.conf or
> /etc/apt/apt.conf.d/*).
>
>> Dear Daniel, you said "- 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?)"
>>
>> Can you please elaborate on that question?
>
> Things like, should the package view be grouped by architecture?
>
> --\ Installed Packages
>  --\ armel
>    --- admin
>    ...
>  --\ powerpc
>    --- admin
>    ...
>
> Or should each package only be shown once (just the name) and
> have the different available architectures elaborated on the
> package info screen?

The problem with showing separate archs separately is there is no easy
way to list the packages then.
In the ideal case they are at least in the same section (but may not
if the section was changed and not all archs are rebuilt) but still
some might be under new, another under installed, another under
uninstalled, ..

Showing the packages for different archs should be easier than
searching all sections.

Sure, you can change the way Aptitude organizes packages but there is
no good UI for that. You have to manually type in the properties by
which the packages should be categorized.

Daniel Hartwig (wigs)
Changed in baltix:
status: New → Invalid
Steve Langasek (vorlon)
Changed in aptitude (Ubuntu Precise):
assignee: Canonical Foundations Team (canonical-foundations) → Colin Watson (cjwatson)
Changed in aptitude (Debian):
status: Fix Committed → Fix Released
Changed in aptitude:
status: Fix Committed → Fix Released
Colin Watson (cjwatson)
tags: removed: rls-p-tracking
Changed in baltix:
status: Invalid → Incomplete
Daniel Hartwig (wigs)
description: updated
Daniel Hartwig (wigs)
Changed in aptitude:
importance: Unknown → Undecided
status: Fix Released → New
Changed in aptitude (Debian):
importance: Unknown → Undecided
status: Fix Released → New
Daniel Hartwig (wigs)
Changed in aptitude:
importance: Undecided → Unknown
status: New → Unknown
Changed in aptitude:
status: Unknown → New
Colin Watson (cjwatson)
Changed in aptitude (Ubuntu):
milestone: ubuntu-12.04 → none
assignee: Colin Watson (cjwatson) → nobody
Daniel Hartwig (wigs)
description: updated
Changed in aptitude (Ubuntu Precise):
milestone: ubuntu-12.04 → ubuntu-12.04.1
Changed in aptitude:
status: New → Confirmed
Colin Watson (cjwatson)
Changed in aptitude (Ubuntu Precise):
milestone: ubuntu-12.04.1 → ubuntu-12.04.2
milestone: ubuntu-12.04.2 → precise-updates
assignee: Colin Watson (cjwatson) → nobody
Daniel Hartwig (wigs)
Changed in aptitude (Debian):
importance: Undecided → Unknown
status: New → Unknown
Daniel Hartwig (wigs)
tags: added: patch
Changed in aptitude (Debian):
status: Unknown → Confirmed
60 comments hidden view all 140 comments
Revision history for this message
Marcin Juszkiewicz (hrw) wrote :

As 0.6.8.1 version of aptitude fixed that bug I merged it into version for quantal. Please check package from http://tygrysek.juszkiewicz.com.pl/~hrw/ubuntu/

Changed in aptitude:
status: Confirmed → Fix Released
Changed in aptitude (Debian):
status: Confirmed → Fix Released
Revision history for this message
Iain Lane (laney) wrote :

Thanks Marcin. This release doesn't seem to need an FFe as it looks like bugfix only, so I've swapped the subscription to ubuntu-sponsors for you. I suggest you attach a debdiff over Debian to make sponsoring easier.

Revision history for this message
Bryce Harrington (bryce) wrote :

Thanks, yes please include a debdiff, and a couple SRU fields still need to be filled out. Please re-subscribe ubuntu-sponsors when this work has been completed.

description: updated
Changed in aptitude (Ubuntu Precise):
status: Triaged → Incomplete
Revision history for this message
Daniel Hartwig (wigs) wrote :

The details on the sponsorship overview are incorrect. This is currently only a request to get the fixed version (0.6.8.1) merged in Quantal. As per the previous comment, that release is only a bug fix.

Changed in aptitude (Ubuntu Precise):
status: Incomplete → Confirmed
Revision history for this message
Daniel Hartwig (wigs) wrote :
Daniel Hartwig (wigs)
description: updated
Daniel Hartwig (wigs)
description: updated
Revision history for this message
Jens Getreu (getreu) wrote :

> As 0.6.8.1 version of aptitude fixed that bug I merged it into version for quantal. Please check package from http://tygrysek.juszkiewicz.com.pl/~hrw/ubuntu/

Is a backport for precise available? Is anyone working on this?

Revision history for this message
YAFU (yafu) wrote :

I think (maybe) the problem is finally fixed with v0.6.8.1
As you know, "ppa-purge" used "aptitude". I have updated the system with the Xorg Edgers PPA repository. I installed "aptitude" v0.6.8.1 in Kubuntu 12.04 Precise. Then ppa-purge has been able to resolve dependencies. It uninstalled google earth and its :i386 dependencies but I have yet some i386 packages installed and the system is not broken.
To install aptitude v0.6.8.1 on Precise, you go to Ubuntu Packages:
http://packages.ubuntu.com/
And search and download the following packages for "Quantal" (not for Precise):

apt
libapt-pkg
libboost-iostreams
libept

Then download from the link posted by Marcin Juszkiewicz ( http://tygrysek.juszkiewicz.com.pl/~hrw/ubuntu ) the next packages:

aptitude-common
aptitude

Save all packages in the same folder. Open the terminal in that folder and install with:

sudo dpkg -i *.deb

Thanks to the developers and creators of the patch.

Revision history for this message
YAFU (yafu) wrote :

> Then ppa-purge has been able to resolve dependencies

I mean using "ppa-purge" with Xorg Edgers PPA.

Revision history for this message
YAFU (yafu) wrote :

Sorry, I've rushed.
Now "aptitude" v0.6.8.1 on Precise can not resolve dependencies when trying to install Google Earth:
http://pastebin.com/eu2ua79c

apt-get can install without problems.

Revision history for this message
Daniel Hartwig (wigs) wrote :

On 3 October 2012 03:27, YAFU <email address hidden> wrote:
> Sorry, I've rushed.
> Now "aptitude" v0.6.8.1 on Precise can not resolve dependencies when trying to install Google Earth:
> http://pastebin.com/eu2ua79c

The proposed solution there looks fine to me, remove some -dev and
misc. packages whose dependencies are being upgraded (and thus, no
longer met). I'm sure one of the subsequent offerings will be to
upgrade most of those packages instead.

>
> apt-get can install without problems.

Please provide the typescript of apt-get for comparison. You should
also skip through several solutions offered by aptitude so that we can
see what is being considered—the order is some times not what the user
expects.

If you wish to pursue this as an issue file a new report as your
experience is not that covered by this bug.

Revision history for this message
YAFU (yafu) wrote :

@Daniel, this is apt-get output:
http://pastebin.com/XBy5CbSH

>If you wish to pursue this as an issue file a new report as your
>experience is not that covered by this bug.

Ok, before I will continue experimenting with aptitude

Revision history for this message
Michael Terry (mterry) wrote :

According to comments here, the 0.6.8.1 release is considered fine for inclusion in quantal by the release team and works for everyone that has tested it. So after some quick smoke tests of my own, I've uploaded it to quantal.

According to comment 104, SRUs are not necessarily requested by this bug. I will close the SRU tasks for precise and oneiric. I'm not sure this would fit the definition of a good SRU candidate anyway.

Changed in aptitude (Ubuntu Oneiric):
status: Triaged → Won't Fix
Changed in aptitude (Ubuntu Precise):
status: Confirmed → Won't Fix
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package aptitude - 0.6.8.1-2ubuntu1

---------------
aptitude (0.6.8.1-2ubuntu1) quantal; urgency=low

  * Resynchronise with Debian to pick up multi-arch fixes (LP: #831768).
    Remaining changes:
    - debian/05aptitude: Never autoremove kernels.
    - Drop aptitude-doc to Suggests.
    - 03_branding: Ubuntu branding.
    - 04_changelog: Take changelogs from changelogs.ubuntu.com.
    - 14_html2text_preferred: Switch back to html2text in favor of elinks,
      since html2text is in main and elinks isn't. Convert all files to utf-8
      encoding as it is better then ascii for iso-8859-1 (English docs).
    - no-google-mock: Don't use google-mock as it and libgtest-dev are in
      universe. Refreshed to cover all changes.
 -- Michael Terry <email address hidden> Wed, 03 Oct 2012 22:55:21 -0400

Changed in aptitude (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Daniel Hartwig (wigs) wrote :

On 4 October 2012 22:14, Michael Terry <email address hidden> wrote:
> So after some quick smoke tests of my own, I've uploaded it
> to quantal.

Appreciated.

> According to comment 104, SRUs are not necessarily requested by this
> bug.

From that comment, with emphasis added:

> This is *currently* only a request to get the fixed
> version (0.6.8.1) merged in Quantal.

The SRUs are not requested yet as the fix [was] not in Quantal. That
comment addresses the prior one regarding various SRU fields not being
filled out and where the commenter appeared mislead by the status of
the sponsoring overview (showing “SRU” instead of “merge”).

> I will close the SRU tasks for precise and oneiric. I'm not sure
> this would fit the definition of a good SRU candidate anyway.

Not being sure about the candidacy should you rather leave it open to
be adjusted by someone who is?

Please confirm your action with the person who opened those tasks or
one of the numerous @ubuntu.com people assigned and otherwise involved
over the course of the bugs life.[1]

As someone familiar with the issue I request that you reopen those
tasks to their previous status and immediately assign them to cjwatson
(previously assigned) or someone else who is informed about this bug.
Such a person is in a better position to take the appropriate
action(s) now required.

Regards

[1] CC to bring this back to their attention now that it is resolved.

Revision history for this message
Michael Terry (mterry) wrote :

> Not being sure about the candidacy should you rather leave it open to
> be adjusted by someone who is?

Saying I wasn't sure was a polite way to say that it didn't seem like a good candidate to me, but I'm happy to have someone else that thinks otherwise push them in.

Additionally, I had read comment #85 as saying that Colin was not interested in pursuing it for precise, but now I think that was a misreading. So I'll open these back up as you request.

Changed in aptitude (Ubuntu Precise):
status: Won't Fix → Confirmed
Changed in aptitude (Ubuntu Oneiric):
status: Won't Fix → Confirmed
Revision history for this message
Colin Watson (cjwatson) wrote :

On Fri, Oct 05, 2012 at 09:08:34AM +0800, Daniel Hartwig wrote:
> As someone familiar with the issue I request that you reopen those
> tasks to their previous status and immediately assign them to cjwatson
> (previously assigned) or someone else who is informed about this bug.

Please don't assign these tasks to me. I won't have time to deal with
them.

Daniel Hartwig (wigs)
description: updated
1 comments hidden view all 140 comments
Revision history for this message
Daniel Hartwig (wigs) wrote :
Revision history for this message
Tim Lunn (darkxst) wrote :

I have tested the precise patch in combination with my ppa-purge patch (Bug #892886), and everything seems to be working smoothly as far as purging packages on a multiarch precise system now.

Revision history for this message
Michael Terry (mterry) wrote :

I'm going to unsubscribe the sponsors team until someone from the SRU team can verify this is the sort of patch that would be accepted. I'd like to get it off the sponsors queue, since there is not anything immediately actionable here from that front.

If you can get buy-in from the SRU team, please re-subscribe the sponsors team. Until then, please don't subscribe them. Thanks!

Revision history for this message
Daniel Hartwig (wigs) wrote :

[1] indicates to have a sponsor upload to -proposed before the Sru team
will review. It states there is no need to wait. The package is unusable
on m-a systems, in Ubuntu main, this upload is a self-contained fix: why
you consider it so unsuitable?

If the package does not get to -proposed, how else to bring this to sru
teams attention?

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

@ Ubuntu SRU Team

Subscribing ubuntu-sru-team.

The precise.debdiff attached to this bug-report is ready for upload into proposed. But there is no clear consensus if such an update is inline with SRU requirements. Can you please review and evaluate the rist of this SRU.

Daniel Hartwig (wigs)
description: updated
Revision history for this message
Daniel Hartwig (wigs) wrote :

Ubuntu SRU Team

Based on the date of your subscription (2012-11-08) the fix /would/ be one of the five oldest entries in the unapproved queue for Precise. It does not appear in that queue as ubuntu-sponsors have declined to upload without prior consideration by your team.

Please consider the report, or at least comment that the team is aware of it.

Revision history for this message
Colin Watson (cjwatson) wrote :

It's a bit scary and would need a lot of testing, but the very poor state of aptitude on multiarch systems in affected releases is a sufficient reason to try for an SRU; so, Dmitrijs or other sponsors, go ahead and upload.

(However, I would suggest removing the "Lack of upstream support" section from "Impact"; true or not, this has no direct bearing on whether we update packages in stable releases.)

Daniel Hartwig (wigs)
description: updated
Revision history for this message
Iain Lane (laney) wrote :

This has been sitting in the queue for ages. It's a shame that we haven't gotten around to uploading this by now (admittedly I myself have had a sponsoring session or two in this time and didn't touch it). I'm building aptitude now and will upload to precise-proposed if it passes smoke tests.

Given the magnitude of this SRU I think extensive testing will be warranted, if it is accepted. Perhaps the waiting period could be extended from 7 days.

I don't know what to upload to Q; please provide a clean debdiff if you wish for an SRU to be uploaded there too. Otherwise, we can leave it as is.

Revision history for this message
Iain Lane (laney) wrote :

So, sponsoring to precise, for what it's worth. I couldn't do much meaningful local testing with multi-arch, possibly because I have some core-ish packages built for amd64 but not i386 in a local repo.

Revision history for this message
Iain Lane (laney) wrote :

Done. Unsubscribing sponsors now. Please resubscribe if there's anything else for us to do, such as sponsoring to Q if a debdiff is provided.

Revision history for this message
Tim Lunn (darkxst) wrote :

Laney, pretty sure it was already fixed in Q,via upstream.

I tested it quite extensively, way back when I was patching ppa-purge. No longer have a precise box to test on though.

Revision history for this message
Daniel Hartwig (wigs) wrote :

On 17 April 2013 17:25, Tim <email address hidden> wrote:
> Laney, pretty sure it was already fixed in Q,via upstream.

Confirm this, with upstream hat on. The fix appears from version 0.6.8.1.

Revision history for this message
Iain Lane (laney) wrote :

Okey doke. The bug still asks for a fix for Oneiric, but I don't know if anyone will be interested in that any more. Thanks!

Changed in aptitude (Ubuntu Precise):
status: Confirmed → In Progress
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Micah, or anyone else affected,

Accepted aptitude into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/aptitude/0.6.6-1ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

description: updated
Changed in aptitude (Ubuntu Precise):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Sven Berkvens-Matthijsse (sven-launchpad) wrote :

The newly uploaded 0.6.6-1ubuntu1.2 version works perfectly for me on a reasonably complicated Precise server with a mixture of i386 and amd64 packages.

Upon starting aptitude, it immediately started complaining about broken packages and all sorts of fixes that it wanted to apply to fix all sorts of problems, so I was skeptical at first. However, this turned out to be because of some pending actions that aptitude still remembered from the last time that I ran aptitude (months ago, just to test whether the problem with multiarch had been fixed without me noticing). Telling aptitude to forget all pending actions got me a perfectly clean system according to aptitude.

Thanks for all the efforts, I love aptitude very much, although I've gotten used to using apt-get as well now :-) Aptitude is much easier to use for selectively upgrading packages, though, which is sometimes necessary on my servers to minimize downtime caused by package upgrades.

Revision history for this message
Stephan Springer (geryon) wrote :

aptitude_0.6.6-1ubuntu1.2_amd64 from precise-proposed fixes this issue for me.

I checked by trying to install wine. The dependency resolution only grumbles about one “recommends” which can't be resolved, which is probably okay. Before it would try to remove (almost?) every package installed.

tags: added: verification-done
removed: verification-needed
Revision history for this message
Daniel Hartwig (wigs) wrote : Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled

On 22 April 2013 18:38, Stephan Springer <email address hidden> wrote:
> I checked by trying to install wine. The dependency resolution only
> grumbles about one “recommends” which can't be resolved, which is
> probably okay.

gettext?

Revision history for this message
Stephan Springer (geryon) wrote :

Yes:

 Actions Undo Package Resolver Search Options Views Help
C-T: Menu ?: Help q: Quit u: Update g: Download/Install/Remove Pkgs
                   Packages Resolve Dependencies
  --\ Keep the following packages at their current version:
    gettext-base:i386 [UNINST]
    gettext:i386 [UNINST]
  --\ Leave the following recommendations unresolved:
    wine1.4-i386:i386 recommends gettext:i386

wine1.4-i386:i386 recommends gettext:i386
--\ The following actions will resolve this dependency:
  -> Install gettext:i386 [0.18.1.1-5ubuntu3 (<NULL>)]
  -> Leave the dependency "wine1.4-i386:i386 recommends gettext:i386" unresolved.

[1(1)/...] Suggest 2 keeps
e: Examine !: Apply .: Next ,: Previous

Revision history for this message
Daniel Hartwig (wigs) wrote :

On 22 April 2013 20:30, Stephan Springer <email address hidden> wrote:
> Yes:

See bug #954029. Trivial fix, could be SRU.

Revision history for this message
Scott Kitterman (kitterman) wrote : Update Released

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package aptitude - 0.6.6-1ubuntu1.2

---------------
aptitude (0.6.6-1ubuntu1.2) precise-proposed; urgency=low

  * Apply upstream multiarch-conflicts.patch to handle conflicts on
    multi-arch systems. (LP: #831768)
 -- Daniel Hartwig <email address hidden> Thu, 08 Nov 2012 14:28:23 +0800

Changed in aptitude (Ubuntu Precise):
status: Fix Committed → Fix Released
Revision history for this message
Daniel Hartwig (wigs) wrote :

Incomplete for too long. No detail given why this should be specifically filed against Baltix.

Changed in baltix:
status: Incomplete → Invalid
Revision history for this message
Daniel Hartwig (wigs) wrote :

Oneiric is no longer supported.

Changed in aptitude (Ubuntu Oneiric):
status: Confirmed → Invalid
Displaying first 40 and last 40 comments. View all 140 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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