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). So in principle no lock is needed here. If some dependencies would be affected you get a warning that you have to resolve.
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.
6. Stuff that would conflict with stuff I build from source
Same thing there. Conflict means you'd have to un-install the system part, but that is missing then and zypper screams :o Solution is to build proper packages in your own repository. I use /usr/src/packages/* tree to compile stuff that I want different from the repo. It's a different vendor, so it won't be touched by usual updates/upgrades, no locks needed. Addditional advantage is that it then has proper dependencies, and zypper itself prevents deinstallation of stuff that your software needs. Because that is one of the largest nuissances with self compilations in /usr/local (or wherever), and has just happened to me again yesterday: You have compiled something against libboost-69, and installed in /usr/local. Now there was the update boost 69->71, which removed all 69 libs :o If your package has the proper dependency on boost 69, that would not have happened - but in /usr/local, the system doesn't know about those needs.
7. Old versions of software needed for off-repo rpm's
Ah yes, that's the case I decribed above. But you forgot one reason: Removal from repo. Stuf that is no longer in the repo gets uninstalled without clear warning. E.g., SuSEFirewall2. I still had that running on my laptop, after discussions on the list suggested it should just continue to work. When it was removed from the repos, zypper just uninstalled it and after the next reboot I stood pants down without firewall....
So, there are different reasons for locking and IMHO there should be different levels of it
a. Lock to prevent installation b. Lock to update/upgrade c. Lock to downgrade d. Lock to prevent removal
Not really sure what you want there. That it is not allowed to be updated, but a downgrade or removal would be fine? So far I haven't needed granularity between those cases, standard lock works fine for that.
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?
On my laptop I now have 59 locks, and on my workstations 51 and 41
Opinions?
Not sure what your goal is. I think different levels of 'lock' wouldn't change the number of locks in your case. If that (reduction) is your goal, get your software properly into the package system, then locks are not really needed in most cases... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org