On 28 December 2016 at 10:48, Aleksa Sarai wrote:

On 12/28/2016 09:16 PM, nicholas wrote:

...

from experience and looking around forums, how to update tumbleweed correctly is not obvious, and not clearly presented. The lack of guidence is causing confusion and problems.

The rest of this post is based on my ASSUMPTION that 'sudo zypper dup --no- allow-vendor-change' is best practice.

AFAIK, "zypper up" is all you need to do -- Tumbleweed is a rolling release so there's no distribution version to update to. In fact, "zypper dup" will probably not do what you want.

`zypper up` is all you need to do, most of the time. It's certainly safe, and won't do anything stupid. but zypper up will rarely/never tidy up after itself, leaving to orphaned packages lurking around over time. These are often benign. zypper up is also very conservative in some aspects of its dependency resolution, so if Tumbleweed or any additional repo package maintainers have done major changes to the dependency tree of a package it's possible zypper up might get tripped up while `zypper dup` will be fine. Of course, zypper dup comes with the additional risk of freely changing repositories, making it practically like russian roulette on a TW machine with OBS devel or home repos present. (Remember, Devel and Home repos do not use the openSUSE Vendor). But this risk is mitigated by `zypper dup --no-allow-vendor-change` which does the tidy up, more relaxed dependency resolution, and yet still ensures you're getting packages from the repositories you as the admin have intended, by only upgrading from the same 'vendor' as the current packages.

zypper dup does not. It's purpose is to allow you to upgrade between Leap versions (or to switch between distributions entirely like Leap -> Tumbleweed).

Yes, but, see above ;) dup still has it's place for Tumbleweed.

...

- Is the dup default of allow-vendor-change really required for leap upgrade?

It shouldn't be, because both vendors are "openSUSE" (IIRC).

Yes, but any additional repos are not "openSUSE", and as the instructions advise removing additional repos and starting from a fresh official-only base, zypper dup gets you there :) Doing a dup with --no-allow-vendor-change from Leap 42.1 to Leap 42.2 on a machine that had additional repos will likely lead to a very broken Leap 42.2 machine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 28 December 2016 at 13:23, nicholas wrote:

On Wednesday, 28 December 2016 10:57:29 CET Richard Brown wrote:

...

On 28 December 2016 at 10:48, Aleksa Sarai wrote:

...

On 12/28/2016 09:16 PM, nicholas wrote:

...

from experience and looking around forums, how to update tumbleweed correctly is not obvious, and not clearly presented. The lack of guidence is causing confusion and problems.

The rest of this post is based on my ASSUMPTION that 'sudo zypper dup --no- allow-vendor-change' is best practice.

AFAIK, "zypper up" is all you need to do -- Tumbleweed is a rolling release so there's no distribution version to update to. In fact, "zypper dup" will probably not do what you want.

`zypper up` is all you need to do, most of the time. It's certainly safe, and won't do anything stupid.

but zypper up will rarely/never tidy up after itself, leaving to orphaned packages lurking around over time. These are often benign.

zypper up is also very conservative in some aspects of its dependency resolution, so if Tumbleweed or any additional repo package maintainers have done major changes to the dependency tree of a package it's possible zypper up might get tripped up while `zypper dup` will be fine.

Of course, zypper dup comes with the additional risk of freely changing repositories, making it practically like russian roulette on a TW machine with OBS devel or home repos present. (Remember, Devel and Home repos do not use the openSUSE Vendor).

But this risk is mitigated by `zypper dup --no-allow-vendor-change` which does the tidy up, more relaxed dependency resolution, and yet still ensures you're getting packages from the repositories you as the admin have intended, by only upgrading from the same 'vendor' as the current packages.

...

zypper dup does not. It's purpose is to allow you to upgrade between Leap versions (or to switch between distributions entirely like Leap -> Tumbleweed).

Yes, but, see above ;) dup still has it's place for Tumbleweed.

...

...

- Is the dup default of allow-vendor-change really required for leap upgrade?

It shouldn't be, because both vendors are "openSUSE" (IIRC).

Yes, but any additional repos are not "openSUSE", and as the instructions advise removing additional repos and starting from a fresh official-only base, zypper dup gets you there :)

Doing a dup with --no-allow-vendor-change from Leap 42.1 to Leap 42.2 on a machine that had additional repos will likely lead to a very broken Leap 42.2 machine.

you have confimed that dup in tumbleweed is still required. however, IMHO the rest of the reply simply: - explains the purpose of each command - states the issues raised together with an algorithmic prescription for workarounds [x is safe, but if xx you need then do to y, z might cause this, xx should, xyx is russian roullette, etc]

If you have a hole in your bucket, the better solution is to plug the hole rather than run around with a mop

it would appear for *TW* that `zypper dup --no-allow-vendor-change` requires no ifs, buts, mights, shoulds or coulds?

apologies, i missed some of the posts when replying: further: (Aleksa)

AFAIK, "zypper up" is all you need to do -- Tumbleweed is a rolling release so there's no distribution version to update to. This proves my point, i did this and ended with a non-conforming system - 'up' does not delete older packages and can get to a state where new packages will not be installed -> does zypper not give you messages "the following packages will not be installed"?

(Richard) You have explained what each command does, since getting my fingers burnt im well aware, most on factory will also be aware. The crux of the post is not a request for help or clarification, it is a statement of the fact that neither 'up' nor 'dup' is the "right tool for the job" on *tumbleweed* and negotiating the between them is not easy for the uninitiated, nor is there any clean solution which is well communicated. Making the analogy to apt-get does not make the minutia of repo consistency any easier. Stating that zypper etc gives you a warning is not a well designed UI. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

2016-12-28 10:52 GMT-02:00 nicholas cunliffe :

...

On 28 December 2016 at 13:23, nicholas wrote:

...

On Wednesday, 28 December 2016 10:57:29 CET Richard Brown wrote:

...

On 28 December 2016 at 10:48, Aleksa Sarai wrote:

...

On 12/28/2016 09:16 PM, nicholas wrote:

...

from experience and looking around forums, how to update tumbleweed correctly is not obvious, and not clearly presented. The lack of guidence is causing confusion and problems.

The rest of this post is based on my ASSUMPTION that 'sudo zypper dup --no- allow-vendor-change' is best practice.

AFAIK, "zypper up" is all you need to do -- Tumbleweed is a rolling release so there's no distribution version to update to. In fact, "zypper dup" will probably not do what you want.

`zypper up` is all you need to do, most of the time. It's certainly safe, and won't do anything stupid.

but zypper up will rarely/never tidy up after itself, leaving to orphaned packages lurking around over time. These are often benign.

zypper up is also very conservative in some aspects of its dependency resolution, so if Tumbleweed or any additional repo package maintainers have done major changes to the dependency tree of a package it's possible zypper up might get tripped up while `zypper dup` will be fine.

Of course, zypper dup comes with the additional risk of freely changing repositories, making it practically like russian roulette on a TW machine with OBS devel or home repos present. (Remember, Devel and Home repos do not use the openSUSE Vendor).

But this risk is mitigated by `zypper dup --no-allow-vendor-change` which does the tidy up, more relaxed dependency resolution, and yet still ensures you're getting packages from the repositories you as the admin have intended, by only upgrading from the same 'vendor' as the current packages.

...

zypper dup does not. It's purpose is to allow you to upgrade between Leap versions (or to switch between distributions entirely like Leap -> Tumbleweed).

Yes, but, see above ;) dup still has it's place for Tumbleweed.

...

...

- Is the dup default of allow-vendor-change really required for leap upgrade?

It shouldn't be, because both vendors are "openSUSE" (IIRC).

Yes, but any additional repos are not "openSUSE", and as the instructions advise removing additional repos and starting from a fresh official-only base, zypper dup gets you there :)

Doing a dup with --no-allow-vendor-change from Leap 42.1 to Leap 42.2 on a machine that had additional repos will likely lead to a very broken Leap 42.2 machine.

you have confimed that dup in tumbleweed is still required. however, IMHO the rest of the reply simply: - explains the purpose of each command - states the issues raised together with an algorithmic prescription for workarounds [x is safe, but if xx you need then do to y, z might cause this, xx should, xyx is russian roullette, etc]

If you have a hole in your bucket, the better solution is to plug the hole rather than run around with a mop

it would appear for *TW* that `zypper dup --no-allow-vendor-change` requires no ifs, buts, mights, shoulds or coulds?

apologies, i missed some of the posts when replying: further: (Aleksa)

...

AFAIK, "zypper up" is all you need to do -- Tumbleweed is a rolling release so there's no distribution version to update to.> This proves my point, i did this and ended with a non-conforming system - 'up' does not delete older packages and can get to a state where new packages will not be installed -> does zypper not give you messages "the following packages will not be installed"?

(Richard) You have explained what each command does, since getting my fingers burnt im well aware, most on factory will also be aware. The crux of the post is not a request for help or clarification, it is a statement of the fact that neither 'up' nor 'dup' is the "right tool for the job" on *tumbleweed* and negotiating the between them is not easy for the uninitiated, nor is there any clean solution which is well communicated. Making the analogy to apt-get does not make the minutia of repo consistency any easier. Stating that zypper etc gives you a warning is not a well designed UI.

Hi,

On a pure oficial tumbluweed (no extra repos) "zypper dup" is all you want.

The moment we start mixing repos (be it a devel, packman or vlc one) we have to take extra care, and the "zypper dup ---no-allow-vendor-change" is the safe choice.

Regards,

Luiz *please* [could new posters refrain from telling me what dup does, and read

On Wednesday, 28 December 2016 11:43:42 CET you wrote: the history] i am well aware of the commands. Users new to tumbleweed are NOT. The information that is supplied is not clear. You can see this from forum posts. (including one of the replies to this thread) yes "zypper dup ---no-allow-vendor-change" should be the *one and only one* *default* and *communicated* method of updating tumbleweed (unless the user has an explicit need otherwise) then we do not need all the [epic poems regarding ifs, buts, mights, shoulds]. Since the command is quite long lets create a shortcut of some sort and include in TW. *Then communicate clearly*. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/28/2016 09:00 AM, nicholas wrote:

yes "zypper dup ---no-allow-vendor-change" should be the *one and only one* *default* and *communicated* method of updating tumbleweed (unless the user has an explicit need otherwise) then we do not need all the [epic poems regarding ifs, buts, mights, shoulds]. Since the command is quite long lets create a shortcut of some sort and include in TW. *Then communicate clearly*.

well from my POV that's not merely 'as clear as mud' but sows confusion and perplexations. Does that me that if you, as I do, have other repositories to ensure latest releases of other things (kernel, tools for specific projects, fixes to specific problems) that one should run the "-dup" ONLY and SPECIFICALLY on the tubleweed repository, replying of the fact that the "--no-allow-vendor-change" means my darktable (for instance) from another repository will not be updated by this 'dup"? Or if that's not the case, then what? Please don't talk about 'locks'. The whole point of those other repositories is that I want either a different style of implementation or a different way of updating. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 28 December 2016 at 17:32, Anton Aylward wrote:

On 12/28/2016 09:00 AM, nicholas wrote:

...

yes "zypper dup ---no-allow-vendor-change" should be the *one and only one* *default* and *communicated* method of updating tumbleweed (unless the user has an explicit need otherwise) then we do not need all the [epic poems regarding ifs, buts, mights, shoulds]. Since the command is quite long lets create a shortcut of some sort and include in TW. *Then communicate clearly*.

well from my POV that's not merely 'as clear as mud' but sows confusion and perplexations.

Does that me that if you, as I do, have other repositories to ensure latest releases of other things (kernel, tools for specific projects, fixes to specific problems) that one should run the "-dup" ONLY and SPECIFICALLY on the tubleweed repository, replying of the fact that the "--no-allow-vendor-change" means my darktable (for instance) from another repository will not be updated by this 'dup"?

Or if that's not the case, then what? Please don't talk about 'locks'. The whole point of those other repositories is that I want either a different style of implementation or a different way of updating.

zypper dup - 'get me the latest packages from wherever, I don't care' Using the darktable example, lets say you have Tumbleweed with a darktable repo chosen and darktable installed from that repo, but you also have other repos enabled (eg packman) When you do a zypper dup you might get darktable from the darktable repo you might get darktable from packman you might get darktable from the official repos it all depends on which package has the highest version number, that's all - that's likely to change stuff in ways you do not expect, which is why I do not consider a plain 'dup' a sensible option for another running additional repos zypper dup --no-allow-vendor-change - 'get me the latest packages from the same vendor/repos I previously installed those packages from' Using the same darktable example, this now means you will always get darktable from the darktable repo, because you originally installed it from the darktable repo Unlike it's no longer in the darktable repo, in which case it'll get it from whatever repo it is available, with a notification of the 'vendor change' All of this is accomplished without locks or micromanagement, zypper is just being smart based on what you've previously installed and from where you've previously installed it. That is why I recommend it as a safer option to zypper dup for day to day patching of complex Tumbleweed+OBS Repo installations. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2016-12-28 17:54, Richard Brown wrote:

zypper dup --no-allow-vendor-change - 'get me the latest packages from the same vendor/repos I previously installed those packages from'

The one problem I have with that approach is that it gives me a long chain of interactive prompts with only one option - could be a bug? Problem: problem with installed package fdupes-1.51-3.19.x86_64 Solution 1: install fdupes-1.61-1.1.x86_64 (with vendor change) http://packman.links2linux.de --> openSUSE Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c): 1 Problem: problem with installed package gstreamer-1.8.2-75.6.x86_64 Solution 1: install gstreamer-1.10.2-1.1.x86_64 (with vendor change) http://packman.links2linux.de --> openSUSE Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c): 1 Problem: problem with installed package gstreamer-0_10-0.10.36-21.7.x86_64 Solution 1: install gstreamer-0_10-0.10.36-20.3.x86_64 (with vendor change) http://packman.links2linux.de --> openSUSE Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c): 1 Problem: problem with installed package gstreamer-0_10-lang-0.10.36-21.7.noarch Solution 1: install gstreamer-0_10-lang-0.10.36-20.3.noarch (with vendor change) http://packman.links2linux.de --> openSUSE and so on... Also this prevents it to work with zypper --non-interactive which one would want for cron-jobs or other mass-updating methods. This is why I use most of the time zypper -n up --no-recommends (where the last arg prevents plenty unwanted packages to be installed) Ciao Bernhard M. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 29.12.2016 09:53, Bernhard M. Wiedemann wrote:

...

The one problem I have with that approach is that it gives me a long chain of interactive prompts with only one option - could be a bug?

On 2016-12-29 08:32, Bernhard M. Wiedemann wrote: tracked in https://bugzilla.opensuse.org/show_bug.cgi?id=1017486

In this case it is not a bug. You asked for "--no-allow-vendor-change". The only solution is a vendor change. Zypper asks if it is alllowed to use this solution (because you explicitly requested it not to). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

...

...

...

The one problem I have with that approach is that it gives me a long chain of interactive prompts with only one option - could be a bug? tracked in https://bugzilla.opensuse.org/show_bug.cgi?id=1017486 In this case it is not a bug.

You asked for "--no-allow-vendor-change". The only solution is a vendor change. Zypper asks if it is alllowed to use this solution (because you explicitly requested it not to). but then when I would omit the option, I get a lot of unwanted vendor changes... The most sane scriptable option atm is calling zypper in -f $packagename for each affected package.

It would be better, if zypper dup asked 1 question instead of 37. And it would be even better, if this could be scripted, e.g.

zypper -n dup --no-allow-vendor-change --except-where-needed

because I want to be able to manage my 100 machines with zypper and doing manual work is not an option for that.

You could try this: yes 1 | zypper dup -y --no-allow-vendor-change -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 29 December 2016 at 08:32, Bernhard M. Wiedemann wrote:

On 2016-12-28 17:54, Richard Brown wrote:

...

zypper dup --no-allow-vendor-change - 'get me the latest packages from the same vendor/repos I previously installed those packages from'

The one problem I have with that approach is that it gives me a long chain of interactive prompts with only one option - could be a bug?

Problem: problem with installed package fdupes-1.51-3.19.x86_64 Solution 1: install fdupes-1.61-1.1.x86_64 (with vendor change) http://packman.links2linux.de --> openSUSE

Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c): 1

Problem: problem with installed package gstreamer-1.8.2-75.6.x86_64 Solution 1: install gstreamer-1.10.2-1.1.x86_64 (with vendor change) http://packman.links2linux.de --> openSUSE

Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c): 1

Problem: problem with installed package gstreamer-0_10-0.10.36-21.7.x86_64 Solution 1: install gstreamer-0_10-0.10.36-20.3.x86_64 (with vendor change) http://packman.links2linux.de --> openSUSE

Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c): 1

Problem: problem with installed package gstreamer-0_10-lang-0.10.36-21.7.noarch Solution 1: install gstreamer-0_10-lang-0.10.36-20.3.noarch (with vendor change) http://packman.links2linux.de --> openSUSE

and so on... Also this prevents it to work with zypper --non-interactive which one would want for cron-jobs or other mass-updating methods.

This is why I use most of the time zypper -n up --no-recommends (where the last arg prevents plenty unwanted packages to be installed)

I understand why you'd want non-interactivity but you need to consider why you get the prompts above In all the cited examples above, the root cause is Packman fdupes, gstreamer, etc have all been dropped from Packman your chosen "zypper -n up --no-recommends" is therefore clinging to orphaned packages like a rotting corpse, and sooner or later your Tumbleweed system will run into issues as other packages depend on newer fdupes, gstreamer, etc which are resolved by using the packages in the official distro This is a perfect case study of precisely why 'zypper dup --no-allow-vendor-change' is my recommended way of patching a Tumbleweed machine - for all the time Packman had fdupes, gstreamer, etc you would have continued receiving updates from them, but now they've restructured what they're doing you currently have your system in an unhealthy state because it no longer reflects where your repositories expect you to be. Of course, when a reluctant vendor change is proposed by zypper, zypper needs to inform you that it is doing something that potentially could have significant consequences on your system. I think zyppers behaviour here is totally sane. It is most certainly not a bug. The problem is that external repositories a rarely maintained in a way that facilitates good smooth upgrades in all circumstances. And in this case, Packman is actually improving, but in order to make those improvements, you have painpoints like this during the transitiions. I think the only viable option for a 100% automated Tumbleweed installation with consistent dependencies is one without any external OBS or Packman repos. This is also true for Leap, which is not immune from the problem cited above. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 28 Dec 2016 11:43:42 -0200, Luiz Fernando Ranghetti wrote:

2016-12-28 10:52 GMT-02:00 nicholas cunliffe :

...

On 28 December 2016 at 13:23, nicholas wrote:

...

On Wednesday, 28 December 2016 10:57:29 CET Richard Brown wrote: [...] [...] [...] [...] [...] [...] [...] [...] [...] [...]

you have confimed that dup in tumbleweed is still required. however, IMHO the rest of the reply simply: - explains the purpose of each command - states the issues raised together with an algorithmic prescription for workarounds [x is safe, but if xx you need then do to y, z might cause this, xx should, xyx is russian roullette, etc]

If you have a hole in your bucket, the better solution is to plug the hole rather than run around with a mop

it would appear for *TW* that `zypper dup --no-allow-vendor-change` requires no ifs, buts, mights, shoulds or coulds?

apologies, i missed some of the posts when replying: further: (Aleksa)

...

AFAIK, "zypper up" is all you need to do -- Tumbleweed is a rolling release so there's no distribution version to update to. This proves my point, i did this and ended with a non-conforming system - 'up' does not delete older packages and can get to a state where new packages will not be installed -> does zypper not give you messages "the following packages will not be installed"?

(Richard) You have explained what each command does, since getting my fingers burnt im well aware, most on factory will also be aware. The crux of the post is not a request for help or clarification, it is a statement of the fact that neither 'up' nor 'dup' is the "right tool for the job" on *tumbleweed* and negotiating the between them is not easy for the uninitiated, nor is there any clean solution which is well communicated. Making the analogy to apt-get does not make the minutia of repo consistency any easier. Stating that zypper etc gives you a warning is not a well designed UI.

Hi,

On a pure oficial tumbluweed (no extra repos) "zypper dup" is all you want.

The moment we start mixing repos (be it a devel, packman or vlc one) we have to take extra care, and the "zypper dup ---no-allow-vendor-change" is the safe choice.

My TW system is for testing and development on the almost bleading edge Act Pri Rfr Type Name URL === === === === ====== ================= ========================================================================================== 1 Yes 99 No rpm-md Archiving-Factory http://download.opensuse.org/repositories/Archiving/openSUSE_Factory 12 Yes 20 No rpm-md hardware-TW http://download.opensuse.org/repositories/hardware/openSUSE_Tumbleweed/ 14 Yes 99 No rpm-md knurpht-TW http://download.opensuse.org/repositories/home:/Knurpht:/unarj/openSUSE_Tumb... 20 Yes 99 No rpm-md Postgres-TW http://download.opensuse.org/repositories/server:/database:/postgresql/openS... 16 Yes 95 No yast2 Non-OSS-TW http://download.opensuse.org/tumbleweed/repo/non-oss 18 Yes 95 No yast2 OSS-TW http://download.opensuse.org/tumbleweed/repo/oss 25 Yes 95 No rpm-md Update-TW http://download.opensuse.org/update/tumbleweed 19 Yes 20 No rpm-md Packman-TW http://ftp.fau.de/packman/suse/openSUSE_Tumbleweed 27 Yes 99 No rpm-md Vivaldi http://repo.vivaldi.com/archive/rpm/x86_64 17 Yes 99 No rpm-md Opera http://rpm.opera.com/rpm I have this system to detect anything "weird" as early as possible, so I don't make the same "mistake" on production boxes The fact that zypper dup is able to *remove* packages from my system is the single reason I do not use it. I use zypper dup when upgrading 13.1 to 13.2 or 13.2 to Leap-42.1 or 42.1 to 42.2 or 13.2 to TW or (well you get the drift). After that I only use zypper up Daily practice: # zypper ref # zypper --no-refresh lp # zypper --no-refresh lu Check weather I want the patches/updates to happen # zypper --no-refresh up -l Linux 4.9.0-1-default [openSUSE Tumbleweed 20161226] HP EliteBook 8560p/1618 Core(TM) i7-2620M CPU @ 2.70GHz/3373(4) x86_64 7933 Mb My system has ± 190 versions of perl My system has almost every browser that runs on Linux (Opera-12 and opera-developer being my main two browsers) /me started using openSUSE when it still was OpenSUSE with version 6

Luiz

-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.25 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/

On 2016-12-28 15:26, nicholas cunliffe wrote:

(carlos) Yes, not for noob, but we could at least make it intelligible and clear to the second user upgrading from say mint, TW is not rawhide. (TW was my first distro! [after 1 day with crashing kubuntu, and 1 day vomiting on Ubuntu's DE])

Congratulations! :-) Old history (or my recollects on it): *) TW is rather an improved factory (and renamed). *) "zypper dup" was initially designed for factory. *) --no-allow-vendor-change is a recent and most wanted addition to cope with systems having several repos. On these, "zypper dup" would destroy the setup, and "zypper up" worked most of the times (although eventually the system degraded). This situation lasted years, so many people became to think that "zypper up" was the appropriate method for TW that we have today. Side note: please trim the quoted material in the posts. ;-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-12-28 16:42, Knurpht - Gertjan Lettink wrote:

Op woensdag 28 december 2016 15:42:59 CET schreef Carlos E. R.:

...

Old history (or my recollects on it):

*) TW is rather an improved factory (and renamed). No. No. No. Factory was a development version, TW is a rolling release. The latter is built exactly like Leap, and goes through openQA just like Leap. Every time updates are released. Except for critical fixes.

I do not agree. For instance, TW does not undergo manual testing and beta phases as Leap does.

...

*) "zypper dup" was initially designed for factory. At that time everything was designed/developed in Factory first. To make zypper able to do an upgrade path to a next openSUSE version.

I mean that it was designed specifically to upgrade factory in day to day usage.

...

*) --no-allow-vendor-change is a recent and most wanted addition to cope with systems having several repos. On these, "zypper dup" would destroy the setup, and "zypper up" worked most of the times (although eventually the system degraded). This situation lasted years, so many people became to think that "zypper up" was the appropriate method for TW that we have today.

Where did you get that information? The advice to use 'zypper dup' has been in de wiki for ages. If you'd use TW and investigate how its updating ( actually upgrading apart from some exceptions ) is done, you'd know this is plain wrong.

It is my expert and considered opinion. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlhj6esACgkQja8UbcUWM1wzIQEAibWu3UkDD7d6sX1WEe0gSgLa pigLafmoxyTTazrMDxEBAIqNzDBIUL7jkCg42kA2zWLrUC/jwJDSkbf5tIHnSQPD =VJPu -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Luiz Fernando Ranghetti [12-28-16 08:46]: [....] (much unnecessary quoting removed)

On a pure oficial tumbluweed (no extra repos) "zypper dup" is all you want.

The moment we start mixing repos (be it a devel, packman or vlc one) we have to take extra care, and the "zypper dup ---no-allow-vendor-change" is the safe choice.

safe is relative.... the judicious use of locks is another "save" path. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-12-29 01:22, Robert Kaiser wrote:

Luiz Fernando Ranghetti schrieb:

...

On a pure oficial tumbluweed (no extra repos) "zypper dup" is all you want.

The moment we start mixing repos (be it a devel, packman or vlc one) we have to take extra care, and the "zypper dup ---no-allow-vendor-change" is the safe choice.

I really want a user interface where I can decently go and mark certain packages as taboo or add them to an update or remove them when they are obsolete or not remove them yet even though they may be obsolete now. Because of that, I always end up in YaST and doing "update all packages if newer version is available".

You should rather do "update unconditionally". It is equivalent to zypper dup.

I would really appreciate if there was an easy, obvious way to do the best and safest choice, i.e. "zypper dup --no-allow-vendor-change" via YaST.

Se above, that's it.

That's IMHO the biggest missing thing in TW nowadays (and almost always was in Factory - though I think a very long time ago the "Factory-Update" module in YaST did something like that).

There are more chances of yast crashing than zypper crashing. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlhkYUEACgkQja8UbcUWM1yf2QD+Kb6y4BX5qsfykSLlxD/rK4gY fjGGyL1qJ285R5Hml9YA/RgGuGFsul18hgGIWd7fNOVAiKJ+fNQurfMqm4GQLJnQ =3Qcm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2016-12-29 13:49, Robert Kaiser wrote:

Carlos E. R. schrieb:

...

You should rather do "update unconditionally". It is equivalent to zypper dup.

No, that would update all packages in my system even if they do not actually have an update, IIRC. That only causes useless downloads and wasted time.

Good point, I forgot.

...

There are more chances of yast crashing than zypper crashing.

Sure, but it's very very rare that it doesn't run through without issue, esp. on TW - actually, I can't remember having any issue at all since TW started (I sometimes did with Factory). On Leap, I do zypper dup for a new version and the YaST variant(s) for in between and I never had an issue there with that.

I have. Whole desktop crash during upgrades. I run zypper in a text mode console for that reason. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

* Richard Brown [12-29-16 08:32]: [....]

This is a stupid way of doing things, of course doesn't do the upgrade as completely as a dup --n-a-v-c would, but it does avoid the problems of desktop crashes during upgrades borking upgrades using a graphical tool at least.

consider: zypper -v dup --no-r -d && zypper -v dup --no-r that way *all* packages are local and ready to apply at once.

In the future, I'm most excited about the prospect of proper 'transactional updates' for Tumbleweed, such as you can see working in concept here: https://github.com/thkukuk/transactional-update

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 30 December 2016 at 13:17, Carlos E. R. wrote:

On 2016-12-29 14:30, Richard Brown wrote:

...

On 29 December 2016 at 12:53, Carlos E. R. <> wrote:

...

On 2016-12-29 13:49, Robert Kaiser wrote:

...

...

I have. Whole desktop crash during upgrades. I run zypper in a text mode console for that reason.

and that's why my 'zypper-twup' alias does "sudo screen zypper dup --no-allow-vendor-change"

Does screen survive when started from a graphical terminal?

Yes, it most certainly does

I thought you needed to have it running from console. That's what I do:

ctrl-alt-f1 login as root start "screen new" ctrl-alt-f7 screen atach (I use tmux, rather) run zypper.

Which is, effectively, running zypper in console.

That seems rather over engineered IMNSHO

...

This is a stupid way of doing things, of course doesn't do the upgrade as completely as a dup --n-a-v-c would, but it does avoid the problems of desktop crashes during upgrades borking upgrades using a graphical tool at least.

In the future, I'm most excited about the prospect of proper 'transactional updates' for Tumbleweed, such as you can see working in concept here: https://github.com/thkukuk/transactional-update

Requires btrfs (snapshots and volumes).

Yes, it does, and the problem with that is what exactly? It's been our default for a while now and today is the last day of 2016, not 2006 or 1996, everyone SHOULD be using btrfs. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Il 31/12/2016 15:01, Carlos E. R. ha scritto:

No, I can not agree with that. Simply put, I do not trust btrfs reliability, and many agree with this. When btrfs has been stable for 10 years (with nearly no new features), I'll reconsider. I have heard too many bad histories of problems.

I in some way, agree with you. For me it's not only a matter of trust but also I don't like how to deal with it. All these subvolumes.... Cow and snapshot will come to XFS and Bcachefs is very promising https://www.patreon.com/bcachefs Bye, Daniele. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Il 01/01/2017 17:58, Johannes Kastl ha scritto:

On 31.12.16 17:02 Daniele wrote:

...

For me it's not only a matter of trust but also I don't like how to deal with it. All these subvolumes....

It surely changes some ways that I have accustomed to, but change in itself is nothing bad, if there is a good reason.

Yes but they should not complicate my life :)

...

Cow and snapshot will come to XFS

So you are going to trust a feature that has just been introduced in a filesystem (not designed a priori for cow)? Or how long are you going to wait for it to become stable? ;-)

No, I will not trust them for a while but al the least, thoose are features added on a solid code. I survived 20 years without cow and snapshot, I'm quite sure that I can survive few years more ;) Daniele. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/31/2016 09:01 AM, Carlos E. R. wrote:

On 2016-12-31 11:05, Richard Brown wrote:

...

On 30 December 2016 at 13:17, Carlos E. R. <> wrote:

...

...

Does screen survive when started from a graphical terminal? Yes, it most certainly does

...

I thought you needed to have it running from console. That's what I do:

ctrl-alt-f1 login as root start "screen new" ctrl-alt-f7 screen atach (I use tmux, rather) run zypper.

Which is, effectively, running zypper in console. That seems rather over engineered IMNSHO I'll test your way forcing an X crash, time permitting, and comment back.

...

...

...

This is a stupid way of doing things, of course doesn't do the upgrade as completely as a dup --n-a-v-c would, but it does avoid the problems of desktop crashes during upgrades borking upgrades using a graphical tool at least.

In the future, I'm most excited about the prospect of proper 'transactional updates' for Tumbleweed, such as you can see working in concept here: https://github.com/thkukuk/transactional-update Requires btrfs (snapshots and volumes). Yes, it does, and the problem with that is what exactly? It's been our default for a while now and today is the last day of 2016, not 2006 or 1996, everyone SHOULD be using btrfs. No, I can not agree with that. Simply put, I do not trust btrfs reliability, and many agree with this. When btrfs has been stable for 10 years (with nearly no new features), I'll reconsider. I have heard too many bad histories of problems.

I fully agree with Carlos, until *I* deem it stable I will not even attempt to use it. And I mean no disrespect to the developers, without testers bugs cannot be found and eliminated. I choose *not* to be a tester, period! Ken Schneider -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/31/2016 02:32 PM, Richard Brown wrote:

On 31 December 2016 at 17:36, Ken Schneider - Factory wrote:

...

...

No, I can not agree with that. Simply put, I do not trust btrfs reliability, and many agree with this. When btrfs has been stable for 10 years (with nearly no new features), I'll reconsider. I have heard too many bad histories of problems.

I fully agree with Carlos, until *I* deem it stable I will not even attempt to use it. And I mean no disrespect to the developers, without testers bugs cannot be found and eliminated. I choose *not* to be a tester, period! Rhetorical question - how will you deem it stable if you don't test it?

If you choose not to be a tester, then you are reliant on the opinions of other testers.

If you're reliant on opinions of other testers, then this one (who just so happens to be a Senior QA Engineer @ SUSE Linux GmbH) says that btrfs is stable and performant enough to be used as a default root filesystem in openSUSE & SUSE Linux Enterprise 12 and later. I am not alone in this opinion - If I was, I'm pretty sure openSUSE & SLE wouldn't have btrfs as their default root filesystems.

If you want to dismiss my opinion, you're more than welcome to and my feelings aren't hurt, but then I would say you have a responsibility to yourself and anyone listening to your opinion to actually do some testing and base your opinion on data of your own gathering.

Otherwise you're not really making a decision, you're just pretending to behind the mask of confirmation bias, and that leads to you missing opportunities to make use of new technologies.

And that would be a shame in my opinion.

Happy New Year With all due respect Richard I fully appreciate all of the hard work *all* of the developers and testers do. But at my age and health issues I have I need as few problems as possible from my electronic devices. I'm to the point where learning new things is becoming extremely difficult, and I'm sure many long users of openSUSE feel the same way. If I had the ability to be a developer I would contribute as well. But you do realize that not everyone has that ability.

-- Ken Schneider S.u.S.E. since 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday 2017-01-01 17:54, Johannes Kastl wrote:

And yes, I am also using btrfs for quite some time and in my use cases it works amazingly well...

"It always works between two bugs", as the saying goes. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 28 December 2016 at 12:52, nicholas cunliffe wrote:

(Richard) You have explained what each command does, since getting my fingers burnt im well aware, most on factory will also be aware. The crux of the post is not a request for help or clarification, it is a statement of the fact that neither 'up' nor 'dup' is the "right tool for the job" on *tumbleweed* and negotiating the between them is not easy for the uninitiated, nor is there any clean solution which is well communicated. Making the analogy to apt-get does not make the minutia of repo consistency any easier. Stating that zypper etc gives you a warning is not a well designed UI.

I would apologise but given your post made it clear you felt the learning curve for zypper was too steep, I thought you would appreciate the context behind some of the status quo Beyond that, your opinion is noted, and I agree with you But whether I agree with you or not is immaterial - someone has to contribute changes to make what me and you think is right into reality Source code is here: https://github.com/openSUSE/zypper Contributors list is here: https://github.com/openSUSE/zypper/graphs/contributors I don't know how much more positive purpose this thread can serve - if you can, please contribute, if you can't, reaching out directly to zypper contributors who can would probably be more productive than pontificating in this mailinglist, especially if you're going to get snippy with someone who was trying to help you - Rich -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I don't know how much more positive purpose this thread can serve - if you can, please contribute, if you can't, reaching out directly to zypper contributors who can would probably be more productive than pontificating in this mailinglist, especially if you're going to get snippy with someone who was trying to help you

I missed this - you have already answered my own [slightly sniping question from my summary email regarding the place for design]. How does one make a contribution, if the articulation of the problem results in hostility? My initial email was quite clear. where i come from we dont go from notion to implimentation, engineering is a process. Linux distros give one a glimpse of the resistence to systemd, a well engineered solution which treatens a cottage industry of confusion. no need to reply to previous emial regarding suggestions. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

...

I don't know how much more positive purpose this thread can serve - if you can, please contribute, if you can't, reaching out directly to zypper contributors who can would probably be more productive than pontificating in this mailinglist, especially if you're going to get snippy with someone who was trying to help you

I missed this - you have already answered my own [slightly sniping question from my summary email regarding the place for design].

How does one make a contribution, if the articulation of the problem results in hostility? My initial email was quite clear.

You've not been exactly "friendly" this entire conversation. Each time someone tried to help you or otherwise explain the situation, you've just shunned them saying "I already know that so stop talking about it, the issue is that zypper is broken because --no-allow-vendor-update is too long, etc." I think most people would agree that Tumbleweed has a documentation problem (for many historical and community related reasons). But you're not going to convince anyone to help update the documentation if you're going to be hostile as soon as someone tries to explain the situation.

where i come from we dont go from notion to implimentation, engineering is a process. Linux distros give one a glimpse of the resistence to systemd, a well engineered solution which treatens a cottage industry of confusion.

Speaking of derailing threads, this is one sure-fire way of getting people to start shouting. [I, for one, don't agree that system is a "well engineered solution". Engineered solutions have a scope, systemd (as a project) does not.] -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

to say '--no-allow-vendor-update' is too long, is an attempt to trivialise the problem. its both too long and not communicated. And its not just documentation, look on the forums. use up / use dup / dont forget to disable repos, then update your other repos [on a system that requires multiple updates per week]

If we fix the documentation, then people will just link to it. I mean, that's what I'd hope, but there's no real way to force people in the forums to post technically correct answers to questions (they are people after all, not automated response scripts).

explaining 'zypper up' is not the solution, it is the problem. your reply was technically wrong, I appreciate your contribution, but I know of no way to communicate that without saying it.

Yes, I was not correct in my comment and I'm actually happy that Richard explained the difference to me (I just ran zypper dup on all of my TW systems). So I do agree that there's a documentation issue, my point was that the way you're going about stating this is very adversarial and is not going to convince people to help you improve the documentation. -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/28/2016 05:48 AM, Aleksa Sarai wrote:

On 12/28/2016 09:16 PM, nicholas wrote:

...

from experience and looking around forums, how to update tumbleweed correctly is not obvious, and not clearly presented. The lack of guidence is causing confusion and problems.

The rest of this post is based on my ASSUMPTION that 'sudo zypper dup --no- allow-vendor-change' is best practice.

AFAIK, "zypper up" is all you need to do -- Tumbleweed is a rolling release so there's no distribution version to update to. In fact, "zypper dup" will probably not do what you want.

Wrong! Even though TW is a rolling release each version *is* a distribution upgrade period.

...

Forums are filled with confusion over the update process e.g. https://forums.opensuse.org/showthread.php/517451-Differnce-between-zypper-u...

That question appears to be talking about a YaST issue. I've been using "zypper up" for the past year, and it's always kept my system up to date.

...

in fact, do zypper up/dup really make sense conceptually or functionally to a rolling distribution?

zypper dup does not. It's purpose is to allow you to upgrade between Leap versions (or to switch between distributions entirely like Leap -> Tumbleweed).

Again, each version of TW *is* a new release which is why "dup" is the recommended way to upgrade.

...

The question, IF the 'no allow vendor change' is best practice, should we make a more accessible command for updating out of the box (i.e. zypper tup/or other) and should best practices not be better communicated to new users?

I recently had to update a Leap install, and I just followed these instructions[1]. And even though I'm far from sane when it comes to keeping my extra repos sane, it still worked properly.

...

- Is the dup default of allow-vendor-change really required for leap upgrade?

It shouldn't be, because both vendors are "openSUSE" (IIRC).

...

[my own learning curve was quite painful, you should not underestimate the conceptual overhead to new user of understanding all the zypper ins and outs regarding 'packages not being updated', 'changing vendor' etc -> your basically expecting the noob to learn *everything* in order to get a working and reliable system within the first few months]

The YaST issue should be fixed (is there an open bug for it?). However, I'm not sure that "noobs" is who openSUSE Tumbleweed is targeting -- a bleeding edge distribution is always going to have some risk of things not working one day. You can't really expect a "noob" to be able to deal with those situations. Leap is much more stable for people like that (and I usually install Leap for people who aren't experts).

[1]: https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/42.2/#upgrade

Ken Schneider -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/28/2016 05:48 AM, Richard Brown wrote:

...

...

- Is the dup default of allow-vendor-change really required for leap upgrade? Yes, in order to ensure you don't have cruft from additional repositories from earlier distribution releases hanging around when there are better upgrade targets available in the main repositories. no-allow-vendor-change is great at ensuring you keep getting your packages from the same sources you currently installed them from, but in the case of a distribution upgrade, that's the last thing you want.

I must admit I'm confused here. Regular readers will recall that I make use of the kernel_Stable repository. I'm running kernel 4.9.0. I also make use of a custom repository for various photographic tools including Darktable, which appears in the main repository. There I'm running 2.3. Similarly I have repositories set up for some more up to date tools that the notional 13.2 system I appear to be running. Again, regular readers will recall I had a problem with my XFS file system a while back. The xfs_repair in xfsprogs that came with the distribution wasn't a late enough version, after all, I'd been updating the kernel. See https://lists.opensuse.org/opensuse/2016-08/msg00448.html. Well the key was getting xfs_repair (>= v4.3). That meant making use of http://download.opensuse.org/repositories/filesystems While filesystems has a tumbleweed branch, that's not so for other custom repositories I use. I'm sorry, but I don't consider making use of up-to-date builds 'cruft'. While 13.2 is coming to the end of its life soon, everything I've seen about the update into the 42 series seems fraught with minor hassles and issues that I don't have time to deal with. Threads like this seem to hint that an upgrade to tumbleweed will also be fraught with 'things that might go wrong'. This, and few other threads recently on the factory and main forums do make me wonder about the future of Suse. I've grown to like it and I'm not sure I'd be comfortable making a change to another system. Please don't even think I might move to ubuntu! -- "Preconceived notions are the locks on the door to wisdom". -- Merry Browne -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Brown composed on 2016-12-28 10:48 (UTC):

nicholas wrote:

...

The question, IF the 'no allow vendor change' is best practice, should we make a more accessible command for updating out of the box (i.e. zypper tup/or other) and should best practices not be better communicated to new users?

I like this idea.

...

- I have 'alias tup=sudo zypper dup --no-allow-vendor-change' in .bashrc

I do something similar

Another option looks like via zypp.conf: solver.dupAllowVendorChange = false Is there any functional difference between it and the cmdline option? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Martin Wilck [01-02-17 11:20]:

On Wed, 2016-12-28 at 23:59 -0500, Felix Miata wrote:

...

Richard Brown composed on 2016-12-28 10:48 (UTC): I like this idea.

...

...

- I have 'alias tup=sudo zypper dup --no-allow-vendor-change' in .bashrc I do something similar

Another option looks like via zypp.conf:

solver.dupAllowVendorChange = false

Is there any functional difference between it and the cmdline option?

And if there is none (as I expect), wouldn't it make sense to set this as default on Tumbleweed, after all what's been said in this thread?

but there is and it *is* adjustable :). I do not want it set to false. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

02.01.2017 19:19, Martin Wilck пишет:

On Wed, 2016-12-28 at 23:59 -0500, Felix Miata wrote:

...

Richard Brown composed on 2016-12-28 10:48 (UTC): I like this idea.

...

...

- I have 'alias tup=sudo zypper dup --no-allow-vendor-change' in .bashrc I do something similar

Another option looks like via zypp.conf:

solver.dupAllowVendorChange = false

Is there any functional difference between it and the cmdline option?

And if there is none (as I expect), wouldn't it make sense to set this as default on Tumbleweed, after all what's been said in this thread?

According to my TW installation, it is set as default already. ## ## EXPERTS ONLY: Per default the solver will not replace packages of ## different vendors, unless you explicitly ask to do so. Setting this ## option to TRUE will disable this vendor check (unless the application ## explicitly re-enables it). Packages will then be considered based on ## repository priority and version only. This may easily damage your system. ## ## CHANGING THE DEFAULT IS NOT RECOMMENDED. ## ## Valid values: boolean ## Default value: false ## # solver.allowVendorChange = false -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

02.01.2017 21:38, nicholas пишет:

...

...

And if there is none (as I expect), wouldn't it make sense to set this as default on Tumbleweed, after all what's been said in this thread? a recipe for confusion? (im a great believer in the principle of least surprise)

...

According to my TW installation, it is set as default already. # solver.allowVendorChange = false there are 2 similiar - check dupAllowVendorChange.

Yes, sorry, this was wrong setting.

long shot - do suse have any near term plans to change dup functionaity and commands a la fedora? (we could then repurpose dup for TW)

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Knurpht - Gertjan Lettink [12-28-16 10:07]: [....]

After a recent discussion: I wouldn't use the word 'noobs'.

??? noob plural noun: noobs a person who is inexperienced in a particular sphere or activity, especially computing or the use of the Internet. merely to identify a particular class, better than lusers -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Carlos E. R. [12-29-16 06:45]:

On 2016-12-28 16:16, Ken Schneider wrote:

...

Going back to the very beginning of TW as it was originally developed by Greg KH it has been recommended to use zypper dup. The reseasoning was very clear, Each release of TW was (and still is) a distribution upgrade meaning it is a brand new release just as going from leap 42.1 to 42.2 is a new release. And using "dup" is still documented as the referred choice in the WIKI for TW.

And the original TW recommended this because it was a Factory derivative, and the recommendation for Factory always was "zypper dup".

and didn't change. i believe it is still "a factory derivative". -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org