Mailinglist Archive: opensuse-factory (269 mails)

< Previous Next >
Re: [opensuse-factory] Lock grades for zypper
On Fri, 20 Sep 2019 17:28:27 +0930, Simon Lees <sflees@xxxxxxx> 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/
< Previous Next >
Follow Ups