Bug 408675

Summary: repository priorities ignored by package management apps
Product: [openSUSE] openSUSE 11.0 Reporter: Jochem Kossen <jkossen>
Component: libzyppAssignee: Michael Schröder <mls>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P4 - Low CC: dmacvicar, forgotten_hovWKlcOPJ, forgotten_zOWss6Gs9u, lslezak, support
Version: Final   
Target Milestone: ---   
Hardware: x86   
OS: openSUSE 11.0   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: screenshot of PackageKit showing updates
screenshot of yast showing updates
y2logs + resolver test case

Description Jochem Kossen 2008-07-12 12:01:13 UTC
I've set the 'packman' repository (nr 3 in the list below) priority to 130 (lower than all other priorities. While zypper behaves correctly, PackageKit and 'yast2 --install' want to update gstreamer packages (which were installed from the Main OSS reository) with gstreamer packages from the packman repository.

myth:/home/jochem # zypper lr -P
#  | Alias                                                    | Name                      | Enabled | Refresh | Priority
---+----------------------------------------------------------+---------------------------+---------+---------+---------
5  | repo-debug                                               | openSUSE-11.0-Debug       | No      | No      | 120     
9  | repo-oss                                                 | openSUSE-11.0-Oss         | Yes     | No      | 120     
10 | repo-non-oss                                             | openSUSE-11.0-Non-Oss     | Yes     | No      | 120     
3  | http://ftp.skynet.be/pub/packman/suse/11.0/              | Packman Repository        | Yes     | Yes     | 130     
1  | openSUSE-DVD 11.0                                        | openSUSE-DVD 11.0         | No      | No      | 99      
2  | Main Repository (OSS)                                    | Main Repository (OSS)     | Yes     | Yes     | 99      
4  | openSUSE-11.0-Updates                                    | openSUSE-11.0-Updates     | Yes     | Yes     | 99      
6  | http://download.videolan.org/pub/videolan/vlc/SuSE/11.0/ | VideoLan Repository       | Yes     | Yes     | 99      
7  | Main Repository (NON-OSS)                                | Main Repository (NON-OSS) | Yes     | Yes     | 99      
8  | http://download.nvidia.com/opensuse/11.0                 | NVIDIA Repository         | Yes     | Yes     | 99

myth:/home/jochem/ # zypper up
Reading installed packages...
Nothing to do.
myth:/home/jochem/ # zypper dup
Reading installed packages...
Nothing to do.
myth:/home/jochem/ #
Comment 1 Jochem Kossen 2008-07-12 12:02:33 UTC
Created attachment 227447 [details]
screenshot of PackageKit showing updates
Comment 2 Jochem Kossen 2008-07-12 12:03:19 UTC
Created attachment 227448 [details]
screenshot of yast showing updates
Comment 3 Cyril Hrubis 2008-07-17 08:06:50 UTC
Please attach y2logs and resolver test case. If you are in doubt follow:

http://en.opensuse.org/Bugs/YaST

Thanks!
Comment 4 Jochem Kossen 2008-07-17 18:26:27 UTC
Created attachment 228548 [details]
y2logs + resolver test case
Comment 5 Forgotten User zOWss6Gs9u 2008-07-19 08:50:11 UTC
Note I reported something similar, but more KDE centric, at bug #402770.
I thing it NEEDS a fix. Repository priorities were implemented in libzypp, but just a single command uses them.

- zypper lu -t package ignores them
- zypper dup ignores them
- kde updater applet, with both libzypp and packagekit backends, ignores them
- YaST QT PM ignores them
- gnome updater aplet ignores them
- YaST GTK PM ignores them

Only zypper up -t package looks at repository priorites!
Comment 6 Jochem Kossen 2008-07-19 09:10:46 UTC
Well, for me, 'zypper up' and 'zypper dup' seem to handle priorities correctly (check the terminal output in the original bug text, they both don't want to update anything, which is correct).

Gnome updater applet does not, and Yast GTK PM does not. They both want to update the system with packages from the packman repository, which has the lowest priority of all activated repositories: 130 (higher number thus lower priority), thus should not be used.
Comment 7 Forgotten User zOWss6Gs9u 2008-07-19 09:30:30 UTC
"zypper up" only updates patches, no packages, and "zypper up -t package" works correctly.

But zypper dup doesn't gives you problems just because the "don't change vendor" rule.

Create a "/etc/zypp/vendors.d/packman" file with content:
---Start file content (do not include)
[main]

vendors=http://packman,packman,videolan
---End file
Put videolan repo with a lower priority than packman. Be sure to have "vlc" or "libffmpeg0" package installed from packman... and "zypper dup" will try to change your packman package with a videolan one.
Comment 8 Forgotten User zOWss6Gs9u 2008-07-19 13:37:11 UTC
Between, yes... "don't change vendor" rule is also ignored by updater applets and YaST PM.
I think that rule isn't documented anywhere, but it's my understanding that is supposed to be applied.

So we have three behaviors:
- zypper lu -t package... the one used by all the GUI apps (or something very similar). Only looks at package version, ignores vendor (bad) and repo priority (bad).
- zypper up -t package... doesn't changes vendor (good) and honours repo priorities (good). "The Good One (TM)".
- zypper dup. It doesn't changes vendor (good), but doesn't honours repo priorities (bad).
Comment 9 Ladislav Slezák 2008-09-01 11:50:28 UTC
*** Bug 416082 has been marked as a duplicate of this bug. ***
Comment 10 Forgotten User hovWKlcOPJ 2009-02-16 19:53:26 UTC
This bug seems to be fixed in openSUSE 11.1. Repository-priorities and dont-change-vendor-rule works here in Yast Packagemanagement.
Comment 11 Forgotten User zOWss6Gs9u 2009-05-09 03:42:13 UTC
Yes, even if YaST sw_single module still does some things in its own instead of through libzypp (locks and vendor are ignored...), the priorities seem to be handled correctly everywhere now.

Any problem with closing the bug?
Comment 12 Duncan Mac-Vicar 2009-05-11 09:46:30 UTC
No, lets close it then.