smartpm sometimes calculates wrong transaction causing packages to be removed/upgraded wrongly

Bug #1086888 reported by Peter Warasin
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Smart Package Manager
New
Undecided
Unassigned

Bug Description

The following situation:
1) efw-locales-* requires the same version as efw-locales
2) endian-appliance requires efw-locales and every efw-locales-* package
3) there are updates for efw-locales, efw-locales-* and endian-appliance*

smart upgrade efw-locales

*should* update only all efw-locales packages, but in reality upgrades many more.

This happens with smart 1.4.1

I attach my debugging output and code which contain the debug prints.
The following should explain why this particular case happens, if you compare with the debug output it should become clear:

1) The package efw-locales is removed because can't coexist with the same but older package -> OK
2) Removing the efw-locales package requires removing all efw-locales-* packages which require efw-locales -> OK
3) Every efw-locales-* package is added to the updown queue, since we need this package really and need to do something later in order to fix -> OK
4) _pending() call: causes to upgrade all efw-locales-* packages, starts with efw-locales-ja -> OK
5) [001] _install(efw-locales-ja-2.10.14-0.endian6@i586) -> OK
6) installation calls _pending with nothing pending -> OK
7) back in recursion to _pending() call #4 (which installed efw-locales-ja)
8) does "Remove every requiring package, or upgrade/downgrade them to something which does not require this dependency", which removes appliance package -> NOT OK

I guess in _pending(), case PENDING_REMOVE, we have those 2 cases (description got from comments) where
1) "Try to install other providing packages."
2) "There's no alternatives. We must remove every requiring package."

Case #2 fixes the problem and has a "continue" at the end of the block, case #1 also fixes, but has no "continue", so the handling after case #2 takes place where packages will be "Then, remove every requiring package, or upgrade/downgrade them to something which does not require this dependency."d

I think case #1 lacks a "continue", since it is already fixed, we do not need to remove the requiring package.

Patch is attached

Revision history for this message
Peter Warasin (peter-endian) wrote :
Revision history for this message
Peter Warasin (peter-endian) wrote :
Revision history for this message
Peter Warasin (peter-endian) wrote :
Revision history for this message
Luca Giovenzana (lucagiove) wrote :

Any feedback on this?
We made some normal test of packages upgrading and we didn't notice any major issue.

Revision history for this message
Luca Giovenzana (lucagiove) wrote :

Just to clarify the test I was referring in the comment above were with Peter's patch..

Changed in smart:
milestone: none → 1.5
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.