On 25/09/2019 17.20, Peter Suetterlin wrote:
H.Merijn Brand wrote:
Short question: are there different kinds of locks available for zypper?
Here are some of the reasons I see for adding locks with zypper al.
1. I do not want software installed on my system:
2. I do not want an installed version to be upgraded/updated
3. I do not want some software to be removed
That's all handled by the same standard lock, isn't it? The reason behind locking isn't relevant, the lock does what you want.
4. I don't want manually added rpm's to be replaced with rep rpm's
Manually added rpms usually have a different vendor, and as such are not touched without notification. 'zypper up' doesn't change vendor, nor does 'zypper dup' in TW (now).
Problem is, when the notification comes, one doesn't remember that this particular package should not be changed. YaST/Zypper do not allow to add our comments to repos. An example: I have Lazarus from the pascal repo. I open YaST, select packman repo, and slect "switch system packages to this repo". Either everything is updated with no question, or with "all" questions. Including Lazarus, which I want to keep on pascal repo. With a hundred questions one may forget about one particular package that needs a different answer. So, I have to do things in this order, and remember it: 1 switch to packman 2 switch to pascal
So in principle no lock is needed here. If some dependencies would be affected you get a warning that you have to resolve.
A message... see above (one may not remember that this package is different).
5. Stuff I build from source
That can e an issue, sort of, in several ways. If you really do a 'make install' that causes lots of issues, if it is intended to *replace* software that is required in the package system. So /usr/local is not a good choice in that case, nor is /opt. The system has to know somehow the software is there, even though there is no package.
/usr/local is the correct place for make install, it is the purpose of that tree.
e. Lock to prevent removal but upgrade/downgrade is allowed
That might indeed be handy in some cases. You might circumvent this by creating a pattern that has that package as requirement?
Not something an admin can do. Only a dev. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)