I’m using Tumbleweed. I have a question regarding whether it is possible to have a single application and its dependencies update from the packman repo — I do NOT want all the other overlapping, installed packages to update from packman. Here’s a representative scenario:
I have the standard four repos enabled with priority 99. I have the packman repo enabled with priority 100 (I don’t want all packman updates).
I have an application, e.g. conky, installed from the standard repo. I want it and its dependencies to update from packman, but, reiterating, without triggering all available system updates from packman.
I can install/update conky to the version in the packman repo via YaST.
But when I “sudo zypper dup”, zypper tries to downgrade conky to the version in the standard repos. I do not want this behavior–I want the system to always prefer the conky package (but only the conky package) from packman.
Is there a way to accomplish this single application “stickyness” to the packman repo, or must I allow all packman updates into my system to get conky updates?
Thanks in advance for any thoughts on this question.
Maybe “zypper up” would be more suitable for what you are doing.
Or use Yast Software management. Search for the application (say “conky”). Right-click and select “update”. Or click the versions tab, and select the version that you want to have installed.
There’s a risk, however. You might finish up with software using libraries that are not compatible with it.
I am not using Tumbleweed (and I think that that is complicating the case, because in a not Tumbleweed situation, you wouldn’t use zypper dup), but did you think about the consequences of what you want?
Depedencies are by nature packages (often containing libraries) the are shared amongst different applications. When you talk about an application and “all it’s dependencies”, I assume you are talking about a package containing one or more executables that depend on the libraries of other packages. But those other packages need not be in the same repo.
E.g. a package in Packman may need a package that is not in Packman at all, but in the OSS repo. And v.v., a package from the OSS repo (some multi-media player) may need a package (a codec) that is as well in the OSS repo as in the Packman repo and one of those is installed, depending if you switched to Packman or not.
And this goes on. Your application package from Packman may need a package from OSS that again needs a package from either Packman or OSS. And a package in Packman may need another package in Packman that the OSS version does not need and is absent in OSS.
IMHO the idea of switching to Packman is that from all the packages residing in both OSS and Packman the Packman ones are installed. And vendor stickyness then garantees that this stays so: only updates belonging to either the Packman or the OSS repo overwrite the packages of the same repo with the new version.
When I understand you correct, you want to make the switch for one package and all packages that are in it’s dependency tree and are also on the Packman repo. I guess strongly that you have to find out yourself by studying that dependency tree which one are both in OSS and in Packman and switch those.
As nrickert warns, your Packman package “A” may need a package that is in Packman and that thus fits your criteria. But at the same time you can have another OSS package “B” that needs the same dependency, but then from OSS. That is impossible to do. When you would also switch that second package “B” to Packman (as done in a general switch) there would be no clash.
Thank you both for your thoughtful responses. You are, of course, correct that I had not fully considered the implications of what I wanted to accomplish in view of how the package manager handles dependencies. I now have a better understanding and I appreciate your input!
Most respectfully yours,
Barry
PS – Is there a way/need to mark this thread “solved” (as I am used to doing in other forums)?