[opensuse-factory] Can I remove locks in TW
Hello to the list, in March I asked the list with the topic "up vs dup with commerical intel compilers installed" Then I locked my intel-rpms (commercial Intel Parallel Studio) but later found that I shall better use a local repository of rpms. Now I want to do another dup. I did zypper locks and removed all locks from packages containing the keyword 'intel' (apparently wildecards don't work). I still have sudo zypper locks # | Name | Type | Repository ---+--------------------------------+---------+----------- 1 | openSUSE | product | (any) 2 | libguilereadline-v-17-17 | package | (any) 3 | Mesa-32bit | package | (any) 4 | gstreamer-plugins-libav | package | (any) 5 | Mesa-dri-nouveau | package | (any) 6 | guile-modules-2_0 | package | (any) 7 | Mesa | package | (any) 8 | dleyna-server | package | (any) 9 | guile1 | package | (any) 10 | kernel-default | package | (any) 11 | kernel-firmware | package | (any) 12 | libdrm-devel | package | (any) 13 | libguile-srfi-srfi-1-v-3-3 | package | (any) 14 | libguile-srfi-srfi-13-14-v-3-3 | package | (any) 15 | libguile-srfi-srfi-4-v-3-3 | package | (any) 16 | libguile-srfi-srfi-60-v-2-2 | package | (any) 17 | libguile17 | package | (any) 18 | guile | package | (any) 19 | libpsm2-2 | package | (any) 20 | libguile-2_0-22 | package | (any) 21 | mingw64-runtime | package | (any) 22 | openSUSE-release | package | (any) 23 | texlive-cleveref | package | (any) An these locks prevent zypper dup. I don't know where these locks come from. Is this normal? I already removed libdrm_intel1 and ibus but fear to continue as I have no glue what I'm doing by that :( sudo zypper dup Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Loading repository data... Reading installed packages... Computing distribution upgrade... 2 Problems: Problem: libdrm-devel-2.4.80-1.1.x86_64 requires libdrm2 = 2.4.80, but this requirement cannot be provided Problem: libdrm-devel-2.4.80-1.1.x86_64 requires libdrm_amdgpu1 = 2.4.80, but this requirement cannot be provided Problem: libdrm-devel-2.4.80-1.1.x86_64 requires libdrm2 = 2.4.80, but this requirement cannot be provided deleted providers: libdrm2-2.4.80-1.1.x86_64 Solution 1: keep obsolete libdrm2-2.4.80-1.1.x86_64 Solution 2: remove lock to allow removal of libdrm-devel-2.4.80-1.1.x86_64 Solution 3: break libdrm-devel-2.4.80-1.1.x86_64 by ignoring some of its dependencies I you tell me it is save to remove all locks I'm happy to do this :) Thanks for your help and please let me know if a forum is a more appropriate place. Fabian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2017-09-26 13:14, Fabian Wein wrote:
Problem: libdrm-devel-2.4.80-1.1.x86_64 requires libdrm2 = 2.4.80, but this requirement cannot be provided deleted providers: libdrm2-2.4.80-1.1.x86_64 Solution 1: keep obsolete libdrm2-2.4.80-1.1.x86_64 Solution 2: remove lock to allow removal of libdrm-devel-2.4.80-1.1.x86_64 Solution 3: break libdrm-devel-2.4.80-1.1.x86_64 by ignoring some of its dependencies
I you tell me it is save to remove all locks I'm happy to do this :)
Hi Fabian, A clean Tumbleweed install does not have any locks and usually upgrades just fine. The problems start when you have packages or repos that do not come from the (nicely integrated+tested) main Tumbleweed repos. I usually do zypper dup --no-recommends --no-allow-vendor-change --force-resolution You should properly review the proposed changes - especially the list of to-be-removed packages and the list of vendor-changes. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2017-09-26 at 15:55 +0200, Bernhard M. Wiedemann wrote:
zypper dup --no-recommends --no-allow-vendor-change ^^^^^^^^^^^^^^^^^^^^^^^^
Just mentioning it again (Steter Tropfen höhlt den Stein): this is the default in Tumbleweed for a few weeks already, see https://lists.opensuse.org/opensuse-factory/2017-07/msg00172.html Cheers, Dominique
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi dominique, only a suggenstion: Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Loading repository data... this message is not really usefull for tumbleweed. could this not be easy extended by '... but if you use tumbleweed "zypper dup --no-recommends --no-allow-vendor-change" is fine and correct' or a little more work: check inside zypper for tumbleweed and show a warning message if 'no zypper dup -- no-allow-vendor-change' is used... this would help maybe not irritate people by this message. (i stumbled upon this message in first time i used) simoN Am 26.09.2017 um 16:00 schrieb Dominique Leuenberger / DimStar:
On Tue, 2017-09-26 at 15:55 +0200, Bernhard M. Wiedemann wrote:
zypper dup --no-recommends --no-allow-vendor-change ^^^^^^^^^^^^^^^^^^^^^^^^
Just mentioning it again (Steter Tropfen höhlt den Stein): this is the default in Tumbleweed for a few weeks already, see https://lists.opensuse.org/opensuse-factory/2017-07/msg00172.html
Cheers, Dominique
- -- B e c h e r e r GmbH Sondermaschinenbau Mauermatten Strasse 22 79183 Waldkirch Germany Tel.: (+49) (0)7681 3134 Fax: (+49) (0)7681 4378 Mail: info@becherer.de Web: www.becherer.de USt-ID-Nr.: DE 814912198 Registergericht: Freiburg HRB 701860 Geschäftsführer: Dipl.-Ing. (FH), EWE Simon H. Becherer Gerichtsstand / Sitz: Waldkirch Es gelten ausschließlich unsere allgemeinen Liefer- und Zahlungsbedingungen / Einkaufsbedingungen: www.becherer.de/AGB -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJZymNXAAoJEOuDxDCJWQG+64AQAIyWZ8gJP66wOEKsDFfaYL7g fcyqQhdN3XEOLDSjfaArCXW/1dshwF++uO2SnJXFarKWGwowqocf1DwaPKYzTXX2 2MDrOvBY2Vs+t6Oo3P0pOn+uMBsVZeUt6ejquzr8quGcjfbrhIdGdJdyfukUDekS A/aQ8XUi84x52WQ5qEflHThLKCPlExT9+Xxn/wY94n4dASLN95fCtwKmsO6qlTyC jSDs/VSDa57lmMxPJukyUZvCPOR2QMQK2Dc/bloHmMQWL1H6AjS5qOLXWk1mY/Xt qd1MtH/IVf+O+cxIyK7BzNV+cNZ+GcxliSMxn26SWVTJHDylRgLS9w2GGgQP8xxC NfQLWjVGsuRZs0ojOQUhKgvDJ9k1GoGncdzNx8o9L4TJ5uhcKJgTtEv+kOdKptbi dQQ+dbOfapSzifkM0p7q63ySriDz3h1inPpFzg6Ig0AO64n19cS9BErikHYfI34s S8FJQglXR7QtGeVej5MhW7nbOnbJnYCRDoO/kwV8sBBhfa64BlJYdT00IB9fp4zl Eebt64eKL+wAG/bqbXgE0TAJiNIyXYg58B8VosOXF9GhYpYf+TsIYFON3YlcuvDJ KnSUoIlVKborgrVlM0FRfOGd2LNmdTnaxp9X5aYR2tTAvk5u8+bS1MMV/srNVRnp FogVUGnOh9gCh5jDMquZ =4Vrz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op dinsdag 26 september 2017 16:25:27 CEST schreef Simon Becherer:
Hi dominique,
only a suggenstion:
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Loading repository data...
this message is not really usefull for tumbleweed.
could this not be easy extended by '... but if you use tumbleweed "zypper dup --no-recommends --no-allow-vendor-change" is fine and correct'
or a little more work: check inside zypper for tumbleweed and show a warning message if 'no zypper dup -- no-allow-vendor-change' is used...
this would help maybe not irritate people by this message. (i stumbled upon this message in first time i used)
simoN
Am 26.09.2017 um 16:00 schrieb Dominique Leuenberger / DimStar:
On Tue, 2017-09-26 at 15:55 +0200, Bernhard M. Wiedemann wrote:
zypper dup --no-recommends --no-allow-vendor-change
^^^^^^^^^^^^^^^^^^^^^^^^
Just mentioning it again (Steter Tropfen höhlt den Stein): this is the default in Tumbleweed for a few weeks already, see https://lists.opensuse.org/opensuse-factory/2017-07/msg00172.html
Cheers, Dominique
-- B e c h e r e r GmbH Sondermaschinenbau Mauermatten Strasse 22 79183 Waldkirch Germany
Tel.: (+49) (0)7681 3134 Fax: (+49) (0)7681 4378 Mail: info@becherer.de Web: www.becherer.de
USt-ID-Nr.: DE 814912198 Registergericht: Freiburg HRB 701860 Geschäftsführer: Dipl.-Ing. (FH), EWE Simon H. Becherer Gerichtsstand / Sitz: Waldkirch
Es gelten ausschließlich unsere allgemeinen Liefer- und Zahlungsbedingungen / Einkaufsbedingungen: www.becherer.de/AGB --no-allow-vendor-change is already default on TW
-- 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 2017-09-26 16:27, Knurpht - Gertjan Lettink wrote:
Op dinsdag 26 september 2017 16:25:27 CEST schreef Simon Becherer:
Hi dominique,
only a suggenstion:
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Loading repository data...
this message is not really usefull for tumbleweed.
could this not be easy extended by '... but if you use tumbleweed "zypper dup --no-recommends --no-allow-vendor-change" is fine and correct'
or a little more work: check inside zypper for tumbleweed and show a warning message if 'no zypper dup -- no-allow-vendor-change' is used...
this would help maybe not irritate people by this message. (i stumbled upon this message in first time i used)
Just mentioning it again (Steter Tropfen höhlt den Stein): this is the default in Tumbleweed for a few weeks already, see https://lists.opensuse.org/opensuse-factory/2017-07/msg00172.html
--no-allow-vendor-change is already default on TW
Still the message: Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Loading repository data... is perhaps not appropriate for TW. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Tue, 2017-09-26 at 19:42 +0200, Carlos E. R. wrote:
Still the message:
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Loading repository data...
is perhaps not appropriate for TW.
Even without vendor change you have to be careful to not have incompatible repos in the list The aim should be to get packages into TW proper and eliminate the need for 3rd party repos (obvious exceptions - but even there, the warning holds true) Cheers Dominique
On 2017-09-26 21:06, Dominique Leuenberger / DimStar wrote:
On Tue, 2017-09-26 at 19:42 +0200, Carlos E. R. wrote:
Still the message:
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Loading repository data...
is perhaps not appropriate for TW.
Even without vendor change you have to be careful to not have incompatible repos in the list
The aim should be to get packages into TW proper and eliminate the need for 3rd party repos (obvious exceptions - but even there, the warning holds true)
But nevertheless, users most do "zypper dup" to properly update tumbleweed, so the warning should not discourage using dup in TW, just that they must take care. They might thing that they should use "zypper up" instead in TW. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Tue, 26 Sep 2017 21:06:04 +0200, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Tue, 2017-09-26 at 19:42 +0200, Carlos E. R. wrote:
Still the message:
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Loading repository data...
is perhaps not appropriate for TW.
Even without vendor change you have to be careful to not have incompatible repos in the list
The aim should be to get packages into TW proper and eliminate the need for 3rd party repos (obvious exceptions - but even there, the warning holds true)
Cheers Dominique
Agree, and I went back from 20+ repo's to this: Act Pri Rfr Type Name URL === === === === ====== ================= =========================================================================================== 1 Yes 99 No rpm-md Archiving-Factory http://download.opensuse.org/repositories/Archiving/openSUSE_Factory/ 10 Yes 99 No rpm-md filesystems-TW http://download.opensuse.org/repositories/filesystems/openSUSE_Tumbleweed/ 13 Yes 20 No rpm-md hardware-TW http://download.opensuse.org/repositories/hardware/openSUSE_Tumbleweed/ 15 Yes 99 No rpm-md knurpht-TW http://download.opensuse.org/repositories/home:/Knurpht:/unarj/openSUSE_Tumb... 21 Yes 99 No rpm-md pgadmin4-Factory http://download.opensuse.org/repositories/home:/auxsvr/openSUSE_Factory/ 22 Yes 99 No rpm-md Postgres-TW http://download.opensuse.org/repositories/server:/database:/postgresql/openS... 17 Yes 95 No yast2 Non-OSS-TW http://download.opensuse.org/tumbleweed/repo/non-oss/ 19 Yes 95 No rpm-md OSS-TW http://download.opensuse.org/tumbleweed/repo/oss/suse/ 28 Yes 95 No rpm-md Update-TW http://download.opensuse.org/update/tumbleweed/ 20 Yes 20 No rpm-md Packman-TW http://ftp.fau.de/packman/suse/openSUSE_Tumbleweed/ 30 Yes 99 No rpm-md Vivaldi http://repo.vivaldi.com/archive/rpm/x86_64/ 18 Yes 99 No rpm-md Opera http://rpm.opera.com/rpm/ where hardware was suggested by this list to solve problems a bit back. Opera is obvious, and I am a alpha-tester and the repo does not conflict. Vivaldi is there because when I started testing it, it still isn't. It is in home:kasza_w_spreju. Postgres is in there because one of the main goals for this box is to test the upcoming version before I install/upgrade on production boxes. Even if incompatible, this is a deliberate and well-considered choise and I am aware of the consequences krurpht was added because of something now in TW, but e.g. unarj still isn't in TW. Archiving still has some uncommon tools that I nneed to support weird Windows customers that send me crazy stuff I have filesystems in there because I want Office-365 integration and that was the only repo that showed packages that would help me. So far I am unsuccessful in that respect though. Followinf M$' docs does not lead to something that works (neither on Windows). -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.27 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Am 2017-09-26 um 16:00 schrieb Dominique Leuenberger / DimStar:
On Tue, 2017-09-26 at 15:55 +0200, Bernhard M. Wiedemann wrote:
zypper dup --no-recommends --no-allow-vendor-change ^^^^^^^^^^^^^^^^^^^^^^^^
Just mentioning it again (Steter Tropfen höhlt den Stein): this is the default in Tumbleweed for a few weeks already, see https://lists.opensuse.org/opensuse-factory/2017-07/msg00172.html
Cheers, Dominique
Why is --no-recommends not default as well? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2017-09-26 at 17:26 +0200, Maximilian Trummer wrote:
Am 2017-09-26 um 16:00 schrieb Dominique Leuenberger / DimStar:
On Tue, 2017-09-26 at 15:55 +0200, Bernhard M. Wiedemann wrote:
zypper dup --no-recommends --no-allow-vendor-change
^^^^^^^^^^^^^^^^^^^^^^^^
Just mentioning it again (Steter Tropfen höhlt den Stein): this is the default in Tumbleweed for a few weeks already, see https://lists.opensuse.org/opensuse-factory/2017-07/msg00172.html
Cheers, Dominique
Why is --no-recommends not default as well?
Because it's wrong - Recommends are there to offere 'a complete' experiecne for applications; if you belive you can live without them, you can't complain if a non-madnatory feature of an application is not running (what you consider mandatory does not have to be mandatory for an application; think about a document viewer like evince: NONE of the formats it supports is mandatory to be supported by the viewer. Several of them, though, we tagged as recommended - based on what the application is most often used for) We have three levels in package dependencies: Requires: the application cannot operate without this dependency Recommends: The application/package is usable, but can miss features. It's up to the packagers to get a balance here Suggests: Additional enhanced features can be added as suggests; An application can potentially do even more than what a majority expects of it. No doubt, though: some packages are a bit eager in recommending other things (e.g. xmlto, converting xml files to other formats, recommending texlive, really?) Cheers, Dominique
On Tue, Sep 26, 2017 at 11:37 AM, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Tue, 2017-09-26 at 17:26 +0200, Maximilian Trummer wrote:
Am 2017-09-26 um 16:00 schrieb Dominique Leuenberger / DimStar:
On Tue, 2017-09-26 at 15:55 +0200, Bernhard M. Wiedemann wrote:
zypper dup --no-recommends --no-allow-vendor-change
^^^^^^^^^^^^^^^^^^^^^^^^
Just mentioning it again (Steter Tropfen höhlt den Stein): this is the default in Tumbleweed for a few weeks already, see https://lists.opensuse.org/opensuse-factory/2017-07/msg00172.html
Cheers, Dominique
Why is --no-recommends not default as well?
Because it's wrong - Recommends are there to offere 'a complete' experiecne for applications; if you belive you can live without them, you can't complain if a non-madnatory feature of an application is not running (what you consider mandatory does not have to be mandatory for an application; think about a document viewer like evince: NONE of the formats it supports is mandatory to be supported by the viewer. Several of them, though, we tagged as recommended - based on what the application is most often used for)
We have three levels in package dependencies:
Requires: the application cannot operate without this dependency Recommends: The application/package is usable, but can miss features. It's up to the packagers to get a balance here Suggests: Additional enhanced features can be added as suggests; An application can potentially do even more than what a majority expects of it.
No doubt, though: some packages are a bit eager in recommending other things (e.g. xmlto, converting xml files to other formats, recommending texlive, really?)
That is not my package, but I personally avoid suggests since there is no support for them in YaST2. That means they are invisible to most users. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2017-09-26 at 12:27 -0400, Todd Rme wrote:
We have three levels in package dependencies:
Requires: the application cannot operate without this dependency Recommends: The application/package is usable, but can miss features. It's up to the packagers to get a balance here Suggests: Additional enhanced features can be added as suggests; An application can potentially do even more than what a majority expects of it.
No doubt, though: some packages are a bit eager in recommending other things (e.g. xmlto, converting xml files to other formats, recommending texlive, really?)
That is not my package, but I personally avoid suggests since there is no support for them in YaST2. That means they are invisible to most users.
Adding recommends instead is approching the issue from the wrong angle though. Let alone that yast DOES show suggests (in the Dependencies tab of a package; but one can't pick and chose there) So, the goal must be to improve the UI, and not use recommends in place of suggests (always keeping in mind: recommends are default auto- installed, suggests are to suggest to the user that something else might make sense too) Cheers Dominique
Op dinsdag 26 september 2017 18:50:34 CEST schreef Dominique Leuenberger / DimStar:
On Tue, 2017-09-26 at 12:27 -0400, Todd Rme wrote:
We have three levels in package dependencies:
Requires: the application cannot operate without this dependency Recommends: The application/package is usable, but can miss features. It's up to the packagers to get a balance here Suggests: Additional enhanced features can be added as suggests; An application can potentially do even more than what a majority expects of it.
No doubt, though: some packages are a bit eager in recommending other things (e.g. xmlto, converting xml files to other formats, recommending texlive, really?)
That is not my package, but I personally avoid suggests since there is no support for them in YaST2. That means they are invisible to most users.
Adding recommends instead is approching the issue from the wrong angle though.
Let alone that yast DOES show suggests (in the Dependencies tab of a package; but one can't pick and chose there)
So, the goal must be to improve the UI, and not use recommends in place of suggests (always keeping in mind: recommends are default auto- installed, suggests are to suggest to the user that something else might make sense too)
Cheers Dominique
Thank you. This made clear that what I understood was correct. -- 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
Op dinsdag 26 september 2017 17:26:20 CEST schreef Maximilian Trummer:
Am 2017-09-26 um 16:00 schrieb Dominique Leuenberger / DimStar:
On Tue, 2017-09-26 at 15:55 +0200, Bernhard M. Wiedemann wrote:
zypper dup --no-recommends --no-allow-vendor-change
^^^^^^^^^^^^^^^^^^^^^^^^
Just mentioning it again (Steter Tropfen höhlt den Stein): this is the default in Tumbleweed for a few weeks already, see https://lists.opensuse.org/opensuse-factory/2017-07/msg00172.html
Cheers, Dominique
Why is --no-recommends not default as well? Because some of us actually want the recommends, f.e. the .lang packages...
-- 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
Op dinsdag 26 september 2017 15:55:05 CEST schreef Bernhard M. Wiedemann:
On 2017-09-26 13:14, Fabian Wein wrote:
Problem: libdrm-devel-2.4.80-1.1.x86_64 requires libdrm2 = 2.4.80, but this requirement cannot be provided deleted providers: libdrm2-2.4.80-1.1.x86_64 Solution 1: keep obsolete libdrm2-2.4.80-1.1.x86_64 Solution 2: remove lock to allow removal of libdrm-devel-2.4.80-1.1.x86_64 Solution 3: break libdrm-devel-2.4.80-1.1.x86_64 by ignoring some of its dependencies
I you tell me it is save to remove all locks I'm happy to do this :)
Hi Fabian,
A clean Tumbleweed install does not have any locks and usually upgrades just fine. The problems start when you have packages or repos that do not come from the (nicely integrated+tested) main Tumbleweed repos.
I usually do zypper dup --no-recommends --no-allow-vendor-change --force-resolution
You should properly review the proposed changes - especially the list of to-be-removed packages and the list of vendor-changes.
You have to find some hierarchic order in your repos, then do zypper dup --from bla --from bla2 --from bla3 and so on then run zypper dup -- 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
A clean Tumbleweed install does not have any locks and usually upgrades just fine. The problems start when you have packages or repos that do not come from the (nicely integrated+tested) main Tumbleweed repos.
I usually do zypper dup --no-recommends --no-allow-vendor-change --force-resolution
You should properly review the proposed changes - especially the list of to-be-removed packages and the list of vendor-changes.
Thanks for the information. I removed all locks, disabled external repostiories (e.g. packman) and dup at the moment. --force-resolution was not known. As resolution I changed vendor several times from packman to openSUSE. I left 32bit hdf5 lib. Interestingly "openSUSE Tumbleweed" anbd openSUSE-release got locked again automatically. The following 3 items are locked and will not be changed by any action: Installed: libhdf5-100-32bit "openSUSE Tumbleweed" openSUSE-release Now I have some conflicts like File /usr/share/qt5/translations/qscintilla_pt_br.qm from install of libqscintilla2_qt5-13-2.10-2.3.x86_64 (openSUSE:Tumbleweed) conflicts with file from package libqscintilla2-qt5-12-2.9.3-1.3.x86_64 (@System) I always wondered about the difference from openSUSE:Tumbleweed and @System?! Thanks :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Fabian Wein <fabian.wein@fau.de> [09-26-17 10:43]: [...]
I always wondered about the difference from openSUSE:Tumbleweed and @System?!
"@System" are files on your system that are not available from the regular tw repos, ie: from another repo which you do not have enabled. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2017-09-26 13:14, Fabian Wein wrote:
Hello to the list,
in March I asked the list with the topic "up vs dup with commerical intel compilers installed"
Then I locked my intel-rpms (commercial Intel Parallel Studio) but later found that I shall better use a local repository of rpms.
Now I want to do another dup. I did zypper locks and removed all locks from packages containing the keyword 'intel' (apparently wildecards don't work).
I still have
sudo zypper locks
Check the contents of the file "/etc/zypp/locks" -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
participants (10)
-
Bernhard M. Wiedemann -
Carlos E. R. -
Dominique Leuenberger / DimStar -
Fabian Wein -
H.Merijn Brand -
Knurpht - Gertjan Lettink -
Maximilian Trummer -
Patrick Shanahan -
Simon Becherer -
Todd Rme