incorrect problem resolution

Bug #441059 reported by Rolf Leggewie
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
aptitude (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: aptitude

Aptitude will incorrectly handle the following situation. Let's say I have package A and package A-extensions installed. Package A recommends package A-extensions. Package A-extensions always depends on the same version of A as itself. Currently, both A and A-extensions are at version 1.1. The upstream repo has 1.2 of A, but is still at 1.1 of A-extensions.

If there are other packages to be updated, aptitude will (correctly IMHO) suggest to hold both A and A-extensions at 1.1. That is fine. If there are no other packages to be updated (after all other packages have been updated), aptitude's only automatic solution is to remove A-extensions. That is definitely wrong, since keeping both packages at the installed version resolves the problem just fine. IMHO, this is also preferred over needlessly removing a package.

Tags: karmic lucid
Revision history for this message
Rolf Leggewie (r0lf) wrote :

speaking in more general terms, aptitude generally fails to accept "keep everything as it is" when there are currently no unresolved conflicts but updates introduce irreconcilable conflicts. Aptitude will not present "hold all packages" as a solution.

tags: added: lucid
Revision history for this message
Rolf Leggewie (r0lf) wrote :

actually, it's worse, aptitude actively creates problems :-(

I have acroread pinned to a self-compiled package that depends on acroread-debian-files. The official package from the partner repository conflicts with acroread-debian-files. All dependencies are resolved and there are no conflicts. But at startup aptitude somehow seems to decide that acroread-debian-files needs to be removed (I assume this is before pinning kicks in) and the package is actually marked as such.

My guess at what's happening is this

1) aptitude is started with all dependencies resolved, no packages to update
2) aptitude sees a newer package for acroread and marks it as a candidate
3) aptitude realizes that acroread-debian-files needs to be removed for 2) and marks the a-d-f package accordingly
4) 2) is rejected due to pinning
5) result: broken state, because the older acroread package needs a-d-f but it's marked for removal

:-(

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

> speaking in more general terms, aptitude generally fails to accept "keep
> everything as it is" when there are currently no unresolved conflicts but
> updates introduce irreconcilable conflicts. Aptitude will not present "hold
> all packages" as a solution.

You may find adding this to /etc/apt/apt.conf relieves the issue:
 Aptitude::ProblemResolver::Discard-Null-Solution "false";

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

Please state what action you are trying to perform. Instructing aptitude to perform a dist-upgrade is different to safe-upgrade, and different again to directly asking for a new version of "package A".

Changed in aptitude (Ubuntu):
status: New → Incomplete
Revision history for this message
Rolf Leggewie (r0lf) wrote :

I will try to provide a test case in the next few days.

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

[Expired for aptitude (Ubuntu) because there has been no activity for 60 days.]

Changed in aptitude (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Daniel Hartwig (wigs) wrote :

Rolf, I think your report may have been the situation described here:

http://bugs.debian.org/511366

which applies to using full-upgrade when the only upgrades available result in breakage.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

Daniel, thank you for keeping an eye on this. I apologize for the late response. Here is my test-case.

1) add "deb http://oss.leggewie.org/LP441059 ./" to sources.list
2) sudo aptitude update;sudo install a a-extensions

This should install version 1.1 of those "packages" (they are simply empty packages with the dependencies set as described in the original report).

3) sudo aptitude

Step 3 should now offer you to remove the a package when doing nothing would be fine. Aptitude::ProblemResolver::Discard-Null-Solution is only a second-best solution. While it defaults to keeping the status quo, it still bugs the admin unnecessarily every time.

My brain is not compatible with the scribbling from Mr Jidanni, I usually have no clue what his babblings are about and this time it's no exception, so I can't comment on whatever he was writing in the Debian BTS.

Changed in aptitude (Ubuntu):
status: Expired → New
Revision history for this message
Rolf Leggewie (r0lf) wrote :

I am now running into another similar issue (some background in bug 1959485) where even with the snippet from comment 3 I am told there are 2 broken packages even after accepting a solution from aptitude resolver to resolve all open issues.

To post a comment you must log in.
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.