On Fri, 20 Sep 2019 17:28:27 +0930, Simon Lees 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/

пʼятниця, 20 вересня 2019 р. 10:58:27 EEST Simon Lees написано:

I install all such software into /opt ie /opt/git then have /opt/git/bin ahead of /usr/bin in my path.

I think if source stuff is primary, better to place it into /usr/local prefix, it's already in $PATH before /usr/bin, and can be used without any additional changes. -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський

On 20/09/2019 16.50, Mykola Krachkovsky wrote:

пʼятниця, 20 вересня 2019 р. 10:30:10 EEST H.Merijn Brand написано:

...

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:

Regular `zypper al x` while x is uninstalled. I'm keeping gnome-keyring uninstalled this way.

...

2. I do not want an installed version to be upgraded/updated

Again, regular lock. It wouldn't be changed.

...

3. I do not want some software to be removed

If this software isn't updated from anywhere... then regular lock would help.

...

4. I don't want manually added rpm's to be replaced with rep rpm's

Create local repository as was mentioned.

...

5. Stuff I build from source

Just install them into /usr/local prefix, it's standard, already in the $PATH before /usr/bin and its purpose for software from non-repo sources, like building from source files.

I thought that /usr/local is for installation without rpm.

...

6. Stuff that would conflict with stuff I build from source

If they still conflict in different prefixes, just uninstall and lock. Did I miss something?

...

7. Old versions of software needed for off-repo rpm's

Again, regular lock, as this stuff wouldn't updated, would it?

...

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 Regular lock

...

e. Lock to prevent removal but upgrade/downgrade is allowed Example? Why it's proposed for removal while it's in repositories?

Maybe because it is superseded by something else.

...

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) Usually I make package in home subrepository in OBS for this stuff, it's not that hard if you are already building them from sources. Local & home (sub)repositories allows you to keep zypper aware of software you've installed, calculate dependencies and also you can manage repository priorities.

I install things without rpm. Some I compile myself.

...

On my laptop I now have 59 locks, and on my workstations 51 and 41

Opinions?

Too many locks. I prefer to manage repositories and keep fewer locks (one for gnome-keyring, I've mentioned). But it's personal taste I think.

I have 14. Telcontar:~ # zypper ll # | Name | Type | Repository ---+---------------------------+---------+----------- 1 | PackageKit | package | (any) 2 | PackageKit-browser-plugin | package | (any) 3 | PackageKit-gtk3-module | package | (any) 4 | apper | package | (any) I do not want pk. 5 | calibre | package | (any) I install without rpm, directly from upstream. 6 | cdrkit-cdrtools-compat | package | (any) Distro wanted to install it, instead of proper cdrtools. 7 | pk-update-icon | package | (any) 8 | plymouth | package | (any) I do not want them. 9 | rekall | package | (any) 10 | rekall-examples | package | (any) 11 | rekall-mysql | package | (any) No longer in distro, to prevent removal. 12 | smapi | package | (any) Mine, obsolete. Prevent removal. 13 | tracker-miner-thunderbird | package | (any) Broken, do not want it. 14 | wodim | package | (any) Do not want it. Telcontar:~ # You see, under the same name (lock) some prevent removal, some prevent installation. It is confusing. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 20/09/2019 19.43, Mykola Krachkovsky wrote:

пʼятниця, 20 вересня 2019 р. 19:55:03 EEST Carlos E. R. написано:

...

...

Just install them into /usr/local prefix, it's standard, already in the $PATH before /usr/bin and its purpose for software from non-repo sources, like building from source files.

I thought that /usr/local is for installation without rpm.

Yeah, that would be more correct.

...

...

...

e. Lock to prevent removal but upgrade/downgrade is allowed

Example? Why it's proposed for removal while it's in repositories?

Maybe because it is superseded by something else.

If something needs it, then this should be resolved by conflict.

...

I install things without rpm. Some I compile myself.

And correct way to install them into /usr/local. But in any case zypper doesn't know about it, it's not in rpm db, zypper can't use it for dependency solving, making rpm — easiest way to do so. OBS for open-source and easy to keep once built for several hosts and might be useful for others. If it's a proprietary code, it's possible to make rpm locally.

...

5 | calibre | package | (any)

I install without rpm, directly from upstream.

Why just don't keep it in OBS?

Upstream recommends not to, for starters. There is an official openSUSE rpm, which is fine. And there are other repos (13 for TW). I'm not going to add another - but anyway, OBS is Greek to me, even though I was a dev.

...

6 | cdrkit-cdrtools-compat | package | (any)

Distro wanted to install it, instead of proper cdrtools.

I can't find this in standard tumbleweed repository…

Yes, old thing, I can probably remove it now (my system is Leap, anyway).

...

7 | pk-update-icon | package | (any)

Not in repository too.

Leap has it.

...

8 | plymouth | package | (any)

I just removed it.

To make sure a package doesn't ever come back, you have to taboo it. YaST does not remember that a package was removed by the admin, a dependency can install it back in the future.

...

9 | rekall | package | (any) 10 | rekall-examples | package | (any) 11 | rekall-mysql | package | (any)

No longer in distro, to prevent removal.

12 | smapi | package | (any)

Mine, obsolete. Prevent removal.

Again, I'd created home repos to keep them.

smapi does not build anymore. rekall I have not tried, but if I do, it would not be with OBS.

...

13 | tracker-miner-thunderbird | package | (any)

Broken, do not want it.

Where did you get it from?

Part of the distro at some point... The current incumbent is tracker-miners (but no mail handler that I can see).

...

14 | wodim | package | (any)

Do not want it.

It's not there...

Fortunately :-)

...

You see, under the same name (lock) some prevent removal, some prevent installation. It is confusing.

So this just to make it easier to read? I can't see a point for this difference from zypper, apart from "allow to update but prevent removing", this might be useful, though I don't remember I needed it.

I don't have a definite opinion, just showing examples :-) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

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)

On Thu, 26 Sep 2019 16:17:29 +0100, Peter Suetterlin wrote:

Carlos E. R. wrote:

...

On 25/09/2019 17.20, Peter Suetterlin wrote:

...

H.Merijn Brand wrote: [...]

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.

Well, the topic was manually installed RPMs. I don't count those from other repos as 'manual install'

Oh, but I do! There is a plethora of very useful repositories available for almost every recent version of openSUSE, but it is strongly advised *against* adding all the repositories as active repositories, as that can lead to conflicts or installation of packages that might be harmful somehow. So I find a piece of software that I want or need and choose the repo I most trust. If this is the *only* package on the repo, I add the repo, use zypper to install the package and then disable the repo. If my work on a certain machine requires me to have that product up-to-date I do not disable it. After installation, any "zypper dup" call would suggest to remove it Manual additions include software I (regret to) require for work. e.g.: zoom, skype, teamviewer, DbSchema, SQL Developer, and MS SQL Server. Others include stuff I really like, but I cannot find in repositories (which can change any day of course) or are commercial: crossover, spotify, dbeaver Some include commercial rpm's for which (by now) repositories exist, but those cannot be updated as that specific version is required for the environment they are used in, e.g. oracle-*.rpm: Instant Client 12.1 is extremely different from 19.3 Then there are packages for which I needed a different version than currently available to get a plugin or other tool working: I want to make useful backups for my Android phone, and home:ahjolinna offers just what I want, but it requires other packages from that repo that conflict with my current TW installation. I just pick what I absolutely need without causing conflicts. To me that is manual installation, but it comes from a repo. IIRC it required wine-mono newer than I have.

...

An example:

I have Lazarus from the pascal repo. I open YaST, select packman repo, and slect "switch system packages to this repo".

TBH, I've never ever used that command, especially for that reason....

...

So, I have to do things in this order, and remember it:

Playing Memory or Sudoku regularly might help making the remembering part easier *veg*

But having the tools to remember it for you is so much easier, isn't it?

...

...

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.

Yes, of course. But it's bad to do this if you intend to *replace* required system parts. Not because of the location per se, but because it's not known to the package system....

...

...

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.

I've never done it, but it should just be creating an rpm with needed dependencies. Try rpm -ql patterns-base-minimal_base rpm -q --requires patterns-base-minimal_base

and likely

zypper si patterns-base

to learn how the spec file looks

I will for sure try to create my own repo locally and add that. This discussion showed at least a few cases where that would be useful -- 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/

Op donderdag 26 september 2019 20:35:07 CEST schreef Carlos E. R.:

One method would be to create a local directory as repo, and put all those package there. Routinely run a zypper dup from that repo as verification that all is Ok.

And have a text file in it explaining where each package there comes from, and why it is there. That's what OBS can do. Branch packages in your repo, build them for 15.x, TW and lots of others. Just add your own home:/ repo to your machine's set.

-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Freitag, 27. September 2019, 08:51:46 CEST schrieb H.Merijn Brand:

The problem wit that is that not all my 15.1 need the same deviating packages (or 15.0 or 42.3 or TW). It completely depends on the function of the box.

• There is only one box that needs to make backups of my phone • There is only one box that needs the MSSQL server installed • There is only one box …

you get the drift

And this is, where different sub projects come into play. Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org