Bug 432960

Summary: new dup algorithm ignores some package updates
Product: [openSUSE] openSUSE 11.0 Reporter: Forgotten User zOWss6Gs9u <forgotten_zOWss6Gs9u>
Component: libzyppAssignee: E-mail List <zypp-maintainers>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: davejplater
Version: Final   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: Community User Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: solver TestCase

Description Forgotten User zOWss6Gs9u 2008-10-07 10:08:31 UTC
Created attachment 243882 [details]
solver TestCase

From http://lists.opensuse.org/zypp-devel/2008-10/msg00016.html

Right now a zypper -v dup returns
The following packages are going to be upgraded:
  k3b-lang-1.0.5-47.1.x86_64  (KDE Backports, openSUSE Build Service)
  ktorrent-3.1.3-7.1.x86_64  (KDE4 Factory Desktop, openSUSE Build Service)
  ktorrent-lang-3.1.3-7.1.x86_64  (KDE4 Factory Desktop, openSUSE Build Service)


The following packages are going to be reinstalled:
  enca-1.9-2.2.x86_64  (Education, openSUSE-Education Community)
  libatlas3-3.8.1-7.2.x86_64  (Education, openSUSE-Education Community)
  release-notes-edu-1100-11.9.noarch  (Education, openSUSE-Education Community)
  stellarium-0.9.1-12.2.x86_64  (Education, openSUSE-Education Community)


The following packages are going to change vendor:
  enca-1.9-2.2.x86_64  (Education, openSUSE-Education Community)
  k3b-lang-1.0.5-47.1.x86_64  (KDE Backports, openSUSE Build Service)
  ktorrent-3.1.3-7.1.x86_64  (KDE4 Factory Desktop, openSUSE Build Service)
  ktorrent-lang-3.1.3-7.1.x86_64  (KDE4 Factory Desktop, openSUSE Build Service)
  libatlas3-3.8.1-7.2.x86_64  (Education, openSUSE-Education Community)
  release-notes-edu-1100-11.9.noarch  (Education, openSUSE-Education Community)
  stellarium-0.9.1-12.2.x86_64  (Education, openSUSE-Education Community)

Ignore Education packages since it seems the repo metadata says the vendor is "openSUSE-Education Community" but the packages say "openSUSE-Education".
The thing is if I make Packman equivalent to any other vendor (through a /etc/zypp/vendors.d/ file) zypper -v up returns:

The following packages are going to be upgraded:
  audacity-1.3.5-2.6.x86_64  (Education, openSUSE-Education Community)
  k3b-1.0.5-47.1.x86_64  (KDE Backports, openSUSE Build Service)
  k3b-lang-1.0.5-47.1.x86_64  (KDE Backports, openSUSE Build Service)
  ktorrent-3.1.3-7.1.x86_64  (KDE4 Factory Desktop, openSUSE Build Service)
  ktorrent-lang-3.1.3-7.1.x86_64  (KDE4 Factory Desktop, openSUSE Build Service)


The following packages are going to change vendor:
  audacity-1.3.5-2.6.x86_64  (Education, openSUSE-Education Community)
  k3b-1.0.5-47.1.x86_64  (KDE Backports, openSUSE Build Service)
  k3b-lang-1.0.5-47.1.x86_64  (KDE Backports, openSUSE Build Service)
  ktorrent-3.1.3-7.1.x86_64  (KDE4 Factory Desktop, openSUSE Build Service)
  ktorrent-lang-3.1.3-7.1.x86_64  (KDE4 Factory Desktop, openSUSE Build Service)

So the question is: why zypper dup ignores k3b and audacity?

Solver testcase attached.
Comment 1 Michael Schröder 2008-10-07 12:23:04 UTC
Hmm, I get lots of updates including the k3b update. Are you sure you're using the Factory libzypp with the new dist upgrade algorithm?
Comment 2 Forgotten User zOWss6Gs9u 2008-10-07 12:54:24 UTC
Isn't zypp:Backport (from Factory) but zypp:svn.

Note that I'm not including the Factory repo, so my list of updates is small.
But:
$ rpm -qa '*zypp*' '*satsolver*'
satsolver-tools-0.11.0-1.1
libzypp-5.14.0-2.1
zypper-0.12.8-1.1

# LC_ALL=C zypper se -i -s zypp satsolver
Loading repository data...
Reading installed packages...

S | Name            | Type    | Version    | Arch   | Repository
--+-----------------+---------+------------+--------+----------------
i | libzypp         | package | 5.14.0-2.1 | x86_64 | ZYPP SVN Builds
i | libzypp         | patch   | 53         | noarch | Updates
i | satsolver-tools | package | 0.11.0-1.1 | x86_64 | ZYPP SVN Builds
i | zypper          | package | 0.12.8-1.1 | x86_64 | ZYPP SVN Builds
i | zypper          | patch   | 114        | noarch | Updates

and "ZYPP_NO_SAT_UPDATE=y zypper dup" (to enable "old dup") returns a different result.

So, yes, I'm pretty sure I'm using the new dist upgrade algorithm.
Comment 3 Michael Schröder 2008-10-07 13:11:09 UTC
Then I don't know what's going on because I get a totally different result.

Hmm, the test cases don't have repo priorities. Do you have different priorities set, i.e. what's the output of 'zypper lr -d'.
Comment 4 Forgotten User zOWss6Gs9u 2008-10-07 13:20:51 UTC
The installed k3b and audacity are from Packman (priority 87), and the updated ones from kde:backports and education (priority 75), so they should be updated. The thing is the k3b-lang situation is exactly the same than the k3b one... but only k3b-lang is updated.

$ zypper lr -pP
#  | Alias                | Nombre               | Activado | Actualizar | Prioridad
---+----------------------+----------------------+----------+------------+----------
5  | home_reddwarf        | RedDwarf's Home      | Si       | Si         | 1        
6  | kde3                 | KDE3                 | Si       | Si         | 25       
8  | kde4_factory_desktop | KDE4 Factory Desktop | Si       | Si         | 25       
10 | kde_qt               | Current Qt 4.x       | Si       | Si         | 25       
11 | mozilla              | Mozilla              | Si       | Si         | 25       
13 | nvidia               | NVIDIA               | Si       | Si         | 25       
20 | smart                | Smart                | Si       | Si         | 25       
24 | wine                 | Wine                 | Si       | Si         | 25       
14 | opensuse-dvd         | openSUSE DVD         | Si       | No         | 50       
17 | repo-debug           | openSUSE Debug       | No       | No         | 50       
18 | repo-non-oss         | openSUSE Non-Oss     | Si       | No         | 50       
19 | repo-oss             | openSUSE Oss         | Si       | No         | 50       
21 | updates              | Updates              | Si       | Si         | 50       
1  | education            | Education            | Si       | Si         | 75       
2  | emulators            | Emulators            | Si       | Si         | 75       
3  | games                | Games                | Si       | Si         | 75       
7  | kde4_community       | KDE4 Community       | Si       | Si         | 75       
9  | kde_backports        | KDE Backports        | Si       | Si         | 75       
12 | network_utilities    | Network Utilities    | Si       | Si         | 75       
15 | opensuse_tools       | openSUSE tools       | Si       | Si         | 75       
23 | virtualbox           | VirtualBox           | Si       | Si         | 75       
25 | yast_svn             | YaST svn snapshots   | Si       | Si         | 75       
26 | zypp_svn             | ZYPP SVN Builds      | Si       | Si         | 75       
16 | packman              | Packman              | Si       | Si         | 87       
4  | home_mvyskocil       | mvyskocil's Home     | Si       | Si         | 93       
22 | videolan             | VideoLan             | Si       | Si         | 99
Comment 5 Michael Schröder 2008-10-07 14:01:40 UTC
Ok, the priorities did the trick. You're right, it is a subtle bug in the code. The installed packages' priorities aren't handled correctly.

The correct result would be to downgrade both k3b and k3b-lang to version 1.0.4-80, as they come from the repo with the best priority.
Comment 6 Forgotten User zOWss6Gs9u 2008-10-07 19:37:18 UTC
Note that "zypper up" updates to the KDE:Backports version. That's the behavior I normally expect from ZYpp.
"Smart" behavior is the one you describe, it would use the package from the repo with the best priority even if that means a downgrade. But until now I never saw zypper downgrading, "up" selects the *upgrade* from the repo with the best priority... but only upgrades are candidates, never downgrades.

So, since I don't want to be the responsible of breaking dup ;-) and since "performs an update of all packages with a special resolver algorithm which takes care of package splits, pattern and product updates, etc." (from man) isn't exactly a precise description... are we all sure a downgrade to 1.0.4-80.1 is the expected behavior?
I suppose this behavior makes sense to avoid the problems we are having with the release numbers in the migration of Factory to the OBS (you put Factory with priority '1' and even if the release number is lower you will still end with the version from Factory), but just to be sure...
Comment 7 Michael Schröder 2008-10-08 11:03:14 UTC
Maybe, but we're talking about 'zypper dup', not 'zypper up'. zypper dup happily downgrads/changes architectures/changes vendors. That's the desired behavior for distribution upgrades.
Comment 8 Forgotten User zOWss6Gs9u 2008-10-09 13:52:25 UTC
OK. But another question, just curiosity... how do you know "installed packages' priorities"? If the installed package is still available in a repo you just look at the repo priority, but if it isn't?
Isn't so uncommon: http://forums.opensuse.org/surveys-polls/395748-little-test-if-you-use-kde3-4-obs-try.html

Smart says the group of installed packages is a new "virtual" repository (rpm-sys) and you can set a priority to this repo, but with ZYpp you can't do the same.
Comment 9 Michael Schröder 2008-10-13 08:35:08 UTC
That's not a problem for the "dup" case, as packages that are no longer available are considered "orphaned" anyway and thus have the lowest priority.
The goal of the "dup" algorithm is to bring all packages to versions from the current repositories.

(Note that the libzypp also has a virtual repository for installed packages. It's called '@System', but I'm not sure if you can specify it's priority somewhere) 
Comment 10 Forgotten User zOWss6Gs9u 2008-10-16 11:27:36 UTC
With
- zypper-0.12.10-2.1
- libzypp-5.16.1-2.1
- satsolver-tools-0.11.1-1.1
from zypp:svn seems fixed.
Comment 11 Michael Schröder 2008-10-16 11:58:19 UTC
Good to hear. Closing this bug...