On Fri, 20 Sep 2019 17:28:27 +0930, Simon Lees <sflees@suse.de> wrote:
On 9/20/19 5:00 PM, H.Merijn Brand wrote:
Short question: are there different kinds of locks available for zypper?
I have solved some of these without locks.
Here are some of the reasons I see for adding locks with zypper al.
1. I do not want software installed on my system:
I personally hate stuff like emacs and zeitgeist, and find installing it is a waste of diskspace, so I blocked them
2. I do not want an installed version to be upgraded/updated
I have locked svn to version 1.8.17, as newer versions do not work well with the svn-to-git conversion tools I use(d). As I do not have any active repository in svn and just use it to import old svn repo's and then convert them to git, I have locked svn at that version
3. I do not want some software to be removed
I still use opera-12 (next to opera-developer), so every update scheme would (and should) remove opera-12 and replace it with something more modern. Every sane user should want that, but I have specific purposes for this browser so I locked it
4. I don't want manually added rpm's to be replaced with rep rpm's
Being forced to work with Oracle, I have a specific set of versioned oracle software that is possibly also available on public (system) repositories. Due to dependencies (probably to be compliant to customer demands) I want to keep these and no other version of it
5. Stuff I build from source
Being involved with (many) open source projects, I have blocked git from installing from the repositories, as I build every version from the sources myself. Having it overwritten by updates from zypper would seriously harm my testing procedures
I install all such software into /opt ie /opt/git then have /opt/git/bin ahead of /usr/bin in my path.
Yes, that works for *many* issues, but not all. I have /pro for stuff I build from source/scratch, but using a different prefix causes some of the tests regarding installations to be ignored. If *you* are the one that is maintaining 'bash', you want to make very very sure that a default installation into /usr will pass and that the procedure is correct. Another thing is that for some software, you as a system admin might require a specific version built from source and be absolutely sure no other version of that software is available on your system as it would break the applications. e.g. because a different version would (automatically) change the format of configuration files of the structure of your database. Here using /opt would be an additional risk instead of a solution
6. Stuff that would conflict with stuff I build from source
Say I build and maintain "fooble" (which might not be publicly available), I might need to block the bimble34 packages that installs any part of fooble and invalidates it
Again because i'm building my software in /opt I avoid such conflicts.
In most cases, yes, but if you are in the position that 3rd party software expects tools to be in a certain space/location, you have no choice. We - the open source community - are well aware that those 3rd parties made bad choices in the past, but if you still have to support customers that depend on those products (of which some are not even available anymore or the company does not exist anymore) you enter a walk of conflicting assumptions.
7. Old versions of software needed for off-repo rpm's
There are packages that (rightfully) would be deleted using zypper dup, but that are needed for older software that is still needed on that machine and is built from source. Zypper dup would e.g. uninstall libfooble-1 as none of the packages requires it and libfooble-4 is now current. I want to keep libfooble-1 and libfooble-1-devel available to be able to build my old stuff
Again here building that version in /opt means I can have the later version for the rest of my system so that doesn't break other things.
I do not understand this. e.g. my software needs libfooble-1 and libfooble-1-devel to compile a certain part of the functionality. Those once were available in the system repo's so 'zypper in libfooble-1 libfooble-1-devel' installed them in the "usual" places. Not /opt or /pro but most likely /usr/lib64 and /usr/include Now when a zypper dup would remove those two, what would /opt help me here? The only workaround involviong /opt is to do an rpm -ql on the packages and move them over to /opt and then modify configurations to find them in configure and/or make.
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 e. Lock to prevent removal but upgrade/downgrade is allowed f. Lock to prevent installation/removal from repo's but make zypper aware that it is installed anyway and ignore further dependencies on this product (like the above git example)
On my laptop I now have 59 locks, and on my workstations 51 and 41
Opinions?
-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/