I know this was set up differently on my old installation. What are the proper settings? I don’t want the Packman stuff getting hosed by other repos taking priority over what I have installed.
In this case, setting Packmans prio to something like ‘50’ should be enough of configuration.
Darn…
This again!
Leave it all at 99
I have tried every conceivable arrangement with this and makes not a dot of difference. And I have yet to have it proved otherwise.
Use the system switch for the repo in software management.
kde: (never mind this is 11.2 pic) http://tinyurl.com/yejwull
gnome: (only in 11.3 on) ImageBam - Fast, Free Image Hosting and Photo Sharing
It does make a difference, what do you think priorities are for?
There is an option in YaST called “Allow Vendor Change” that by default is unchecked (menu: Options). Shouldn’t this make sure that the hosing of Packman stuff (and similar) doesn’t happen?
Prove and explain please…
Because the behaviour is nothing like it was in versions earlier than 11.2
Well, I have about 25 repositories activated on my system (11.2) and that would just not work if priorities did not make a difference. If it does not work as expected I recommend to read the man-pages or file a bug report (sorry caf, but what you try to suggest here is just nonsense).
From what I can tell, changing priorities won’t change vendors, and shouldn’t. You must specifically determine this. The only thing priority does is set the refresh order, but maybe you’ve found something else.
I plan to keep my nonsensical approach then. Did it in 11.2, 11.3 and now 11.4
All at 99
And use the package switcher as required (or zypper dup -r <repo#>)
We’ll leave it at that then. And @ FlameBait can take pot luck.
The only thing priority does is set the refresh order, but maybe you’ve found something else.
The refresh order? What’s that?
Anyway, for me it makes a big difference:
hoppers:~ # zypper lr -p | grep Packman
11 | Packman | Packman | Yes | Yes | 70
hoppers:~ # zypper dup
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Loading repository data...
Reading installed packages...
Computing distribution upgrade...
Nothing to do.
hoppers:~ # zypper mr -p 99 11
Repository 'Packman' priority has been set to 99.
hoppers:~ # zypper lr -p | grep Packman
11 | Packman | Packman | Yes | Yes | 99
hoppers:~ # zypper dup
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Loading repository data...
Reading installed packages...
Computing distribution upgrade...
The following NEW packages are going to be installed:
libIL1 liballeg4_4
The following packages are going to be REMOVED:
allegro libdevil1
The following packages are going to be upgraded:
GeoIP audacity cdparanoia crafty dssi flexdock gamin gamin-server hedgewars hedgewars-data jakarta-commons-net kaffeine laf-plugin libGeoIP1 libOIS1_2_0 libSoundTouch0 libass4
libaubio2 libcaca0 libcdda_interface0 libcdda_paranoia0 libdirac_decoder0 libdirac_encoder0 libdvdread-devel libdvdread4 libenca0 libfm libfm-gtk0 libfm0 libfreebl3 libmenu-cache1
libmtp-devel libmtp8 libopencv2 libprojectM2 libsoftokn3 libtag-extras1 libtheora0 libtinyxml0 libxine-devel libxine1 libxine1-gnome-vfs libxine1-pulse marble marble-data
menu-cache meterbridge mozilla-js192 mozilla-nss mozilla-nss-certs mozilla-nss-devel mozilla-xulrunner192-translations-common p7zip python-numpy python-simplejson python-wxGTK
qtractor skinlf soundtouch sox streamtuner streamtuner-doc sweep tvbrowser
The following package is going to be downgraded:
digikam
The following packages are going to change vendor:
GeoIP http://packman.links2linux.de -> openSUSE
audacity http://packman.links2linux.de -> obs://build.opensuse.org/multimedia
cdparanoia http://packman.links2linux.de -> openSUSE
crafty http://packman.links2linux.de -> openSUSE-Education
dssi http://packman.links2linux.de -> openSUSE-Education
flexdock http://packman.links2linux.de -> openSUSE-Education
gamin http://packman.links2linux.de -> : openSUSE-LXDE
gamin-server http://packman.links2linux.de -> : openSUSE-LXDE
hedgewars http://packman.links2linux.de -> obs://build.opensuse.org/games
hedgewars-data http://packman.links2linux.de -> obs://build.opensuse.org/games
jakarta-commons-net http://packman.links2linux.de -> openSUSE
kaffeine http://packman.links2linux.de -> obs://build.opensuse.org/KDE
laf-plugin http://packman.links2linux.de -> openSUSE-Education
libGeoIP1 http://packman.links2linux.de -> openSUSE
libOIS1_2_0 http://packman.links2linux.de -> obs://build.opensuse.org/games
libSoundTouch0 http://packman.links2linux.de -> openSUSE
libass4 http://packman.links2linux.de -> openSUSE
libaubio2 http://packman.links2linux.de -> openSUSE
libcaca0 http://packman.links2linux.de -> openSUSE-Education
libcdda_interface0 http://packman.links2linux.de -> openSUSE
libcdda_paranoia0 http://packman.links2linux.de -> openSUSE
libdirac_decoder0 http://packman.links2linux.de -> openSUSE
libdirac_encoder0 http://packman.links2linux.de -> openSUSE
libdvdread-devel http://packman.links2linux.de -> openSUSE
libdvdread4 http://packman.links2linux.de -> openSUSE
libfm http://packman.links2linux.de -> : openSUSE-LXDE
libfm-gtk0 http://packman.links2linux.de -> : openSUSE-LXDE
libfm0 http://packman.links2linux.de -> : openSUSE-LXDE
libfreebl3 http://packman.links2linux.de -> obs://build.opensuse.org/mozilla
libmenu-cache1 http://packman.links2linux.de -> : openSUSE-LXDE
libmtp-devel http://packman.links2linux.de -> openSUSE
libmtp8 http://packman.links2linux.de -> openSUSE
libopencv2 http://packman.links2linux.de -> obs://build.opensuse.org/KDE
libprojectM2 http://packman.links2linux.de -> obs://build.opensuse.org/KDE
libsoftokn3 http://packman.links2linux.de -> obs://build.opensuse.org/mozilla
libtag-extras1 http://packman.links2linux.de -> obs://build.opensuse.org/KDE
libtheora0 Packman -> obs://build.opensuse.org/games
libtinyxml0 http://packman.links2linux.de -> obs://build.opensuse.org/games
libxine-devel http://packman.links2linux.de -> obs://build.opensuse.org/multimedia
libxine1 http://packman.links2linux.de -> obs://build.opensuse.org/multimedia
libxine1-gnome-vfs http://packman.links2linux.de -> obs://build.opensuse.org/multimedia
libxine1-pulse http://packman.links2linux.de -> obs://build.opensuse.org/multimedia
marble openSUSE -> obs://build.opensuse.org/KDE
marble-data openSUSE -> obs://build.opensuse.org/KDE
menu-cache http://packman.links2linux.de -> : openSUSE-LXDE
meterbridge http://packman.links2linux.de -> obs://build.opensuse.org/multimedia
mozilla-js192 http://packman.links2linux.de -> obs://build.opensuse.org/mozilla
mozilla-nss http://packman.links2linux.de -> obs://build.opensuse.org/mozilla
mozilla-nss-certs http://packman.links2linux.de -> obs://build.opensuse.org/mozilla
mozilla-nss-devel http://packman.links2linux.de -> obs://build.opensuse.org/mozilla
mozilla-xulrunner192-translations-common http://packman.links2linux.de -> obs://build.opensuse.org/mozilla
p7zip http://packman.links2linux.de -> openSUSE
python-numpy http://packman.links2linux.de -> obs://build.opensuse.org/games
python-simplejson http://packman.links2linux.de -> openSUSE
python-wxGTK http://packman.links2linux.de -> openSUSE
qtractor http://packman.links2linux.de -> obs://build.opensuse.org/multimedia
skinlf http://packman.links2linux.de -> openSUSE-Education
soundtouch http://packman.links2linux.de -> openSUSE
sox http://packman.links2linux.de -> obs://build.opensuse.org/multimedia
streamtuner http://packman.links2linux.de -> obs://build.opensuse.org/multimedia
streamtuner-doc http://packman.links2linux.de -> obs://build.opensuse.org/multimedia
sweep http://packman.links2linux.de -> obs://build.opensuse.org/multimedia
tvbrowser http://packman.links2linux.de -> obs://build.opensuse.org/multimedia
64 packages to upgrade, 1 to downgrade, 2 new, 2 to remove, 63 to change vendor.
Overall download size: 135.2 MiB. After the operation, additional 15.2 MiB will be used.
Continue? [y/n/?] (y): n
I like this method very much. As I have very little Packman currently installed I’ll have to remember to update it every time I install a new package to 11.3.
I thought repo priority had to do with update precidence? So now I am kind of confused but switching the source wholesale in the software manager seems a really good method of dealing with the issue that bypasses that.
My old install had a pretty ugly list of repos. I found I had this old xbox huge image of it in my pictures directory on my webhost.
http://www.slhess.com/pictures/repo1.jpg
People don’t normally do a dup, but I guess the effect is the same. A package update will keep the old vendor.
I would not and do not recommend a general use of ‘dup’
To a specific repo, yes. But not system wide. Least not for the typical user.
I take your point and agree you are correct. But I am sure for zypper up, it makes no odds.
FlameBait, have you read my previous post? I hope it explains what priorities actually do and especially when they take effect: in case you allow vendor changes (either with the YaST-option mentioned here or via ‘zypper dup’ instead of ‘zypper up’). If you do system-updates without allowing vendor changes (which is the regular way) priorities indeed do not make a difference, in that case switching those packages once does the trick.
Edit:
caf, of course priorities do only take effect in case vendor changes are accepted. Otherwise it would not make any sense at all. But that’s pretty much what the manual says.
That was the big problem in 11.1
We had to get folks to switch the Updates repo to match OSS (120), get packman to a higher priority (lower number), so it would over-ride updates. The issue was compounded by folks pushing for the latest kde4 too
Hence the arrival of the switcher in 11.2, which for the normal user is great. But there are still some problems. One particular, is if you add mozilla repo, you must switch to it after packman. Or if you do a packman switch again at anytime, do mozilla after it. Because packman has some mozilla packages which break mozilla.
Either way - the priorities now offer a very clear function which is well documented, so I don’t really see the problem here. Its purpose is to prioritize sources of software in case two or more vendors offer the same package in different versions if vendor changes are allowed, period. It is true that a ‘zypper dup’ should not be recommended as the usual way of updating (I do it all the time, but I know how to deal with conflicts), but as helpers we can not really know how the user will configure future update processes. Priorities are there and they have a reason, ignoring them doesn’t really help or explain.
Um… just for the record: as you can see in my example I do use several Mozilla-packages from Packman and they do not break Mozilla apps at all. The Packmen and -women wouldn’t build those if that was the case, would they?
This was confusing as I would go in and check my Packman repo in 11.1 and see all kinds of stuff to upgrade (and downgrade) which I had to do manually. With everything at 99 with a vendor change applied this well take care of itself.(I hope :D) Now I just need to remember to apply the vendor change when I install new packages from Packman.
One thing to consider:
In the past, the whole OS build service has been regarded ONE vendor. If this is still a fact, then priorities and a plain “zypper up” are still related.
Because a “dup” does not mean “allow repo change” but “allow vendor change”.
We had this some months ago, though 
I have a hard time trying to understand what the problem is with priorities. Priorities are… that, priorities, every dictionary explains them pretty well.
The man page for zypper also has a good enough explanation:
Packages from repositories with higher priority will be preferred even in case there is a higher installable version available in the repository with a lower priority.
Or, from the YaST’s “Software Repositories” help:
Priority of a repository is an integer value between 0 (the highest priority) and 200 (the lowest priority). Default priority is 99. If a package is available in more repositories the repository with the highest priority is used.
Name it “preference order” if you prefer. But it’s just that simple. Sometimes ZYpp will be able to select between multiple packages from different repositories… in such situations from which repository you prefer it to select the package? Order the repositories in your preference order and ZYpp will take your preference into account when it has to select a package.
There are rules, as the don’t change vendor in updates, that have priority over user’s preferences? Sure, but this doesn’t changes anything. ZYpp is just saying that in case after all these rules have been applied there are still multiple options… which one you prefer?
Now, if someone really needs a list of situations where user’s preferences will be taken into account:
- zypper in <package>
And also from YaST’s “Software Management”. When you select a package to install, the version that will be selected by default depends of the repo priorities. - zypper in --from <repo> <package>
<package> will be installed from <repo>, but any uninstalled dependency of <package> will be selected from the repo with the highest priority. - zypper dup
As already shown. - zypper dup --from <repoA> --from <repoB>
Yes, you can do this, is in the manual. Packages will be selected from repoA or repoB depending of theirs priorities. This probably will help with the Packman vs Mozilla problem caf4926 has, but I have not used it too much… - zypper up
packageA 1.0 is updated to packageA 1.1. packageA 1.1 requires a new package, packageB, that wasn’t required by packageA 1.0. From which repo packageB will be installed? From the one with the highest priority.
This has changed. But that doesn’t means every repo will have a different vendor.
home:RedDwarf and every home:RedDwarf:* repo (but home:RedDwarf:ardni) have the same vendor.
In general “subrepos” have the same vendor, but the subrepo maintainer can change that.
But still, a repo can copy packages from another repo, and so it could happen that different packages from a single repo have different vendors. As an example, liballeg4_4 from home:RedDwarf has as vendor “obs://build.opensuse.org/Emulators” instead of “obs://build.opensuse.org/home:RedDwarf”. What all this means? Only that repos and vendors are totally different things, don’t confuse them.
But you don’t need to know any of this… Just say what’s your preference. What do you prefer, Coke or Pepsi? Easy? Now say if in general you prefer packages from Packman or from the main repo. And if you don’t have preferences, just set the same priority to every repo. Again, where is the problem?
Well explained, RedDwarf - might be worth a Wiki-article.