[opensuse-factory] Lock grades for zypper
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: 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 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 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 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/
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.
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.
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.
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?
-- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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/
On 9/20/19 10:39 AM, H.Merijn Brand wrote:
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:
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
Why not building it in your own project on build.opensuse.org, add the repo on your machine, install the RPM from there, and then always use the '--no-allow-vendor-change' option for updates? Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
пʼятниця, 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 9/21/19 12:03 AM, Mykola Krachkovsky wrote:
пʼятниця, 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.
Because if i''m working on project "foo" and project "baa" and they both depend on different versions of the same library or tool "cats" then you can end up with two versions of cats in /usr/local that may conflict or do nasty things to each other where as if I put "foo" in /opt/foo and "baa" in /opt/baa I can then have multiple versions of "cats" in each, and if I choose to no longer care about baa then I can just rm -f /opt/baa rather then running make uninstall on a bunch of things in /usr/local which might uninstall parts of something I care about for another project. So generally I find the trade off of greater flexibility worth while for needing to add something extra to my path or create an extra symlink into /opt/bin. Having said that in my current job I pretty much don't need anything in /opt although in the past I have had a reasonable amount there. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op vrijdag 20 september 2019 09:30:10 CEST schreef 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:
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
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
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
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? Re. the Oracle stuff: You could create your own local repo ( simple rpm folder ) and do a zypper dup --from LOCALREPONAMEHERE . That would stop zypper from replacing them with distro versions.
-- 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
пʼятниця, 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.
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?
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.
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. -- 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)
пʼятниця, 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?
6 | cdrkit-cdrtools-compat | package | (any)
Distro wanted to install it, instead of proper cdrtools.
I can't find this in standard tumbleweed repository…
7 | pk-update-icon | package | (any)
Not in repository too.
8 | plymouth | package | (any)
I just removed it.
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.
13 | tracker-miner-thunderbird | package | (any)
Broken, do not want it.
Where did you get it from?
14 | wodim | package | (any)
Do not want it.
It's not there...
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. -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
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)
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
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)
Carlos E. R. wrote:
On 25/09/2019 17.20, Peter Suetterlin wrote:
H.Merijn Brand wrote:
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.
Well, the topic was manually installed RPMs. I don't count those from other repos as 'manual install'
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*
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.
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 26 Sep 2019 16:17:29 +0100, Peter Suetterlin <pit@astro.su.se> 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/
On 26/09/2019 17.55, H.Merijn Brand wrote:
On Thu, 26 Sep 2019 16:17:29 +0100, Peter Suetterlin <pit@astro.su.se> 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!
Of course they are.
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.
Yes. 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.
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....
It is documented in the wiki and other places, almost as a mandatory step after installing openSUSE.
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 is what we use computers for. To automate things.
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
Oh, I know how they look. They look Very complicated.
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
-- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
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
On Fri, 27 Sep 2019 00:21:34 +0200, Knurpht-openSUSE <knurpht@opensuse.org> wrote:
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.
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 -- 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/
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
participants (8)
-
Bernhard Voelker -
Carlos E. R. -
H.Merijn Brand -
Hans-Peter Jansen -
Knurpht-openSUSE -
Mykola Krachkovsky -
Peter Suetterlin -
Simon Lees