[opensuse-factory] updating tumbleweed - best practices
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. Forums are filled with confusion over the update process e.g. https://forums.opensuse.org/showthread.php/517451-Differnce-between-zypper-u... I have seen other suggestions of (including by forum global moderator) 'zypper up' mostly, 'zypper dup' occasionally, this is without clarfying to disable extra repos. https://forums.opensuse.org/showthread.php/504212-I-get-no-updates-to-Tumble... there are also MANY implicit postings of problems suggesting the OP is not even aware of the issues. The current update process would appear: non-evident (not communicated, ambiguous (when to up/dup?), non deterministic (its ok to get out of sync sometimes?), error prone (new user forgets to disable extra repos), time consuming mess. in fact, do zypper up/dup really make sense conceptually or functionally to a rolling distribution? 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 have 'alias tup=sudo zypper dup --no-allow-vendor-change' in .bashrc - Is the dup default of allow-vendor-change really required for leap upgrade? [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] -- 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: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.
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).
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 -- 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 28 December 2016 at 10:48, Aleksa Sarai <asarai@suse.de> 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 Wednesday, 28 December 2016 10:57:29 CET Richard Brown wrote:
On 28 December 2016 at 10:48, Aleksa Sarai <asarai@suse.de> 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? -- 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 <ndcunliffe@gmail.com> wrote:
On Wednesday, 28 December 2016 10:57:29 CET Richard Brown wrote:
On 28 December 2016 at 10:48, Aleksa Sarai <asarai@suse.de> 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 <ndcunliffe@gmail.com>:
On 28 December 2016 at 13:23, nicholas <ndcunliffe@gmail.com> wrote:
On Wednesday, 28 December 2016 10:57:29 CET Richard Brown wrote:
On 28 December 2016 at 10:48, Aleksa Sarai <asarai@suse.de> 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 -- 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 <ndcunliffe@gmail.com>:
On 28 December 2016 at 13:23, nicholas <ndcunliffe@gmail.com> wrote:
On Wednesday, 28 December 2016 10:57:29 CET Richard Brown wrote:
On 28 December 2016 at 10:48, Aleksa Sarai <asarai@suse.de> 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
Op woensdag 28 december 2016 15:00:19 CET schreef nicholas:
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*.
I agree here, 100 %. Love the plan. For no other than reasons of logic. We cannot know what a user may add repo-wise. We even offer a "Plain RPM folder" as an option to add repositories. So, whatever's in there, the user will no want to be replaced by some version that ( suddenly ) appears in some other repo and break from the local repo. My rule for TW users: 'zypper dup --no- allow-vendor-change' is always OK, 'zypper dup' most of the time. -- 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 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 2016-12-28 18: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"?
"zypper dup --no-allow-vendor-change" tries to update every package from the same repo, so yes, it would try to keep "darktable" and would not be altered. But notice I said "tries"; some times it fails. For instance, your darktable might depend on another package that is not available, and then might be removed or replaced. But what Nicholas is asking for is simply for clear documented policy, I suppose on a wiki page explaining how to upgrade TW (specifically, TW). Not for explanations on what each method does. The problem is, there is no agreement. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 28 December 2016 at 17:32, Anton Aylward <opensuse@antonaylward.com> 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 12/28/2016 12:54 PM, 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'
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.
Thank you very much for that explanation, Richard. Its clear in my mind now. Just one more question: If I'm not using Tumbleweed/factory and do a 'zypper dup --no-allow-vendor-change' will that clear out cruft? For various definitions of cruft that you might clarify. -- "It doesn't matter who votes, it matters who counts the votes" -- Joe Stalin -- 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
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 -- 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
On 2016-12-29 14:46, Stefan Seyfried wrote:
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). 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. Ciao Bernhard M. -- 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
* Aleksa Sarai <asarai@suse.de> [12-29-16 14:28]:
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
yes, that *would* be a fine solution/work-a-round provided the questions always were numbered alike, which they are not :( -- (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 29 December 2016 at 08:32, Bernhard M. Wiedemann <bernhardout@lsmod.de> 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 Thursday, 29 December 2016 08:59:12 CET Richard Brown wrote:
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
I agree and `zypper dup --no-allow-vendor-change` is working perfectly for me on my "Leap 42.2 development server" as part of a daily automatic update. I have the official main repos enabled plus some for the applications I am active part of the development, e.g. openQA, python-openqa_review, and according dependencies. The above command does the automatic update nearly every time automatically. Only in the case we move dependencies around, e.g. python-configparser was part of my home repo, is now part of devel:languages:python, others were previously part of d:l:p and are now part of official Leap 42.2 because I submitted them to Factory and then to Leap accordingly. In these cases the automatic command will inform me by email about the suggested move, I login manually, select the appropriate choice or whatever I find suitable, and continue from there. -- 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 <elchevive68@gmail.com> wrote:
2016-12-28 10:52 GMT-02:00 nicholas cunliffe <ndcunliffe@gmail.com>:
On 28 December 2016 at 13:23, nicholas <ndcunliffe@gmail.com> 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/
(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]) (H.Merijn Brand) you appear a long term power user with a very individual setup, conflating the issue with the requirements of a punctual distro. On 28 December 2016 at 15:15, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
On Wed, 28 Dec 2016 11:43:42 -0200, Luiz Fernando Ranghetti <elchevive68@gmail.com> wrote:
2016-12-28 10:52 GMT-02:00 nicholas cunliffe <ndcunliffe@gmail.com>:
On 28 December 2016 at 13:23, nicholas <ndcunliffe@gmail.com> 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/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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)
Op woensdag 28 december 2016 15:42:59 CET schreef Carlos E. R.:
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). 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.
*) "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.
*) --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.
Side note: please trim the quoted material in the posts. ;-)
Done :) -- 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
-----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
On Wednesday, 28 December 2016 17:35:55 CET Carlos E. R. wrote:
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.
You might call TW an infinite Beta release. Some users already rely on the very fast early adopters and only update their TW after some days (e.g. on weekends) in case nobody reported horror stories on opensuse-factory :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Luiz Fernando Ranghetti <elchevive68@gmail.com> [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
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". 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. 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). Cheers, KaiRo -- 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
Carlos E. R. schrieb:
-----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.
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.
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.
No, it's not. It's way more work to do for one thing.
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.
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. KaiRo -- 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)
On 29 December 2016 at 12:53, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2016-12-29 13:49, Robert Kaiser wrote:
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.
and that's why my 'zypper-twup' alias does "sudo screen zypper dup --no-allow-vendor-change" The screen means the upgrade will continue regardless of whether or not the desktop or tty I am running it from explodes spectacularly, even though it happens very rarely. for the equivalent of 'zypper up', openSUSE GNOME also takes care of this problem by using the GNOME Software update mechanism. Packagekit downloads all of it's patches, then offers the user to reboot to install them. When that user choses to reboot, systemd boots into a special 'upgrade' target, which only patches the system and then reboots again into the patched system. 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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Richard Brown <RBrownCCB@opensuse.org> [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 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? 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.
The screen means the upgrade will continue regardless of whether or not the desktop or tty I am running it from explodes spectacularly, even though it happens very rarely.
Yes, it is rare, but I have seen it happen, specially as I don't upgrade TW every week.
for the equivalent of 'zypper up', openSUSE GNOME also takes care of this problem by using the GNOME Software update mechanism. Packagekit downloads all of it's patches, then offers the user to reboot to install them. When that user choses to reboot, systemd boots into a special 'upgrade' target, which only patches the system and then reboots again into the patched system.
Interesting. I don't use gnome recently, nor package kit, though.
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). I have seen a similar concept on expensive systems running unix. They basically changed links to the old/new files. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 30 December 2016 at 13:17, Carlos E. R. <robin.listas@telefonica.net> 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
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. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
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
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.
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? ;-) I suggest using btrfs that has been in use and developement for quite some time. And yes, some of its code is not that old, and some of its feature are quite new and unstable. But we are talking filesystem and cow here, and that I believe is rock solid (while RAID5/6 etc. may be not and I am not using them and thus have no experience...). Johannes
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 2017-01-01 17:58, Johannes Kastl wrote:
On 31.12.16 17:02 Daniele wrote:
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 use it. I will wait for comments from others for some years. Some of the devs are common for both projects. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
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 31 December 2016 at 17:36, Ken Schneider - Factory <suse-list3@bout-tyme.net> 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 -- 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 <suse-list3@bout-tyme.net> 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 31.12.16 20:32 Richard Brown wrote:
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.
I would say that is one very well put statement that I can truly agree to. Thanks Richard! And yes, I am also using btrfs for quite some time and in my use cases it works amazingly well... Johannes
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
* Jan Engelhardt <jengelh@inai.de> [01-01-17 12:17]:
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.
Which is true of all things, software/filesystems, your choice. I must say that I did have an early problem with filled root filesystem but was easily resolved with help for this list. I have not had another problem with btrfs since and have utilized snapshots to correct several personal misdeeds. but I do use tw extensively and do expect an occasional hiccup, but I see no more than when I utilized a more normal choice of operating system even though that was quite some time ago. -- (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 28 December 2016 at 12:52, nicholas cunliffe <ndcunliffe@gmail.com> 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
to quickly summerize previous emails: - an algorithm: if x then y; else if xx then yy ; else...... - relied on algorithm but did not ensure consistency - a misunderstanding of the use of 'zypper up' on TW - a misunderstanding of what ---no-allow-vendor-change actually does - conflation with the handling of Leap - the inapropriate use of locks - various rants none of them as simple or clear as using "zypper dup ---no-allow-vendor- change" for the typical update
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 understood
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 if we decide on a way forward i will happily change the code.
The purpose of the post was to: 1 - articulate a perceived problem, solicit points of view, check understanding. 2 - get proposals on a solution, decide on implementation implementation has not been decided, there are several options: [remembering that TW users may update several times a week] a - simply be more aware and consistent in recommending the use of zypper dup ---no-allow-vendor-change" in documentation/forums etc b - (hack) add an alias to .bashrc --> better tell the user to add it. c - adding a new command to zypper e.g. ldup (l for locked) -> SUSE might object? d - [probably the cleanest/easiest] adding a new flag zypper dup --lock (or simply dup -L or -LV) (as in Lock Vendor) *my vote is for zypper dup -LV* (if factory mailing list is not the place to collaborativly work on solving a problem, and creating consensus for the implimention of changes - you should let me know -> how is TW design actually done?) -- 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
On 28 December 2016 at 20:58, nicholas <ndcunliffe@gmail.com> wrote:
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.
I think you have interpreted hostility where there is none, not from me and not from the other people who have been helping you on this thread
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.
My guide on how to contribute to openSUSE, which directly addresses the question as to how I expect openSUSE contributors to contribute is here: https://rootco.de/2016-04-03-opensuse-and-you/ The short version is, we're a project where "those who do, decide", the process is lightweight and contribution driven, and we most certainly strive to go from notion to implementation as fast and as quickly as possible, with our communication channels like this mailinglist are intended to be used to facilitate and accelerate that.. -- 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] 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. as has been pointed out, this is not the place for that kind of debate, apologies if feathers where ruffled. systemd comment, my twisted humour :) On 28 December 2016 at 22:27, Aleksa Sarai <asarai@suse.de> wrote:
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 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
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 if we decide on a way forward i will happily change the code.
The purpose of the post was to: 1 - articulate a perceived problem, solicit points of view, check understanding. 2 - get proposals on a solution, decide on implementation
implementation has not been decided, there are several options: [remembering that TW users may update several times a week] a - simply be more aware and consistent in recommending the use of zypper dup ---no-allow-vendor-change" in documentation/forums etc b - (hack) add an alias to .bashrc --> better tell the user to add it. c - adding a new command to zypper e.g. ldup (l for locked) -> SUSE might object? d - [probably the cleanest/easiest] adding a new flag zypper dup --lock (or simply dup -L or -LV) (as in Lock Vendor)
*my vote is for zypper dup -LV*
What does your proposed -LV do? Is it just an alias of --no-allow-vendor-change? Why not come up with some shorthands for all of the --no-allow flags?
(if factory mailing list is not the place to collaborativly work on solving a problem, and creating consensus for the implimention of changes - you should let me know -> how is TW design actually done?)
Once people agree that something is a problem, you should submit either a bug report or a FATE request. Other users can vote on FATE requests to increase their "priority". But a FATE request is overkill if you just want to add a flag to zypper. Mailing lists aren't the best method of getting everyone's input on how to fix a particular issue. They're more suited to gauging interest or asking questions, simply because: a. They derail very quickly. b. In many cases the actual developers of <thing being discussed> don't respond to threads about <thing being discussed> because they filter the mailing list (or aren't subscribed / don't check it). -- 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 28 December 2016 at 10:16, nicholas <ndcunliffe@gmail.com> 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.
Forums are filled with confusion over the update process e.g. https://forums.opensuse.org/showthread.php/517451-Differnce-between-zypper-u...
I have seen other suggestions of (including by forum global moderator) 'zypper up' mostly, 'zypper dup' occasionally, this is without clarfying to disable extra repos. https://forums.opensuse.org/showthread.php/504212-I-get-no-updates-to-Tumble...
there are also MANY implicit postings of problems suggesting the OP is not even aware of the issues.
The current update process would appear: non-evident (not communicated, ambiguous (when to up/dup?), non deterministic (its ok to get out of sync sometimes?), error prone (new user forgets to disable extra repos), time consuming mess.
in fact, do zypper up/dup really make sense conceptually or functionally to a rolling distribution?
zypper up/upgrade makes sense as a conservative upgrade choice It's very similar in concept and function to the 'apt upgrade' function which has since been renamed to 'apt safe-upgrade' FYI zypper dup/dist-upgrade is similar in concept and function to 'apt dist-upgrade' which has since been renamed to 'apt full-upgrade' I think both up and dup have their place in zypper and ergo in Tumbleweed also, but I do feel the best practice for a day-to-day upgrade is `zypper dup --no-allow-vendor-change`
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
- 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.
[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]
As you might have gathered from some of my points above, there is a lot in common in concepts between zypper and aptitude, so any knowledge you may have or be able to find from there is likely to transfer rather smoothly, at least at a high level until you get down and dirty with zypper or RPM specifics. -- 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
On 28 December 2016 at 15:03, Anton Aylward <opensuse@antonaylward.com> wrote:
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.
Why? are you involved in Tumbleweed kernel testing? If not ,then the correct way to consume a new kernel is to wait until it's actually tested and in Tumbleweed properly.
I'm sorry, but I don't consider making use of up-to-date builds 'cruft'.
The 'cruft' comes when devel projects, which have no qualty controls and no standards, restructure and remove packages, leading to zypper up leaving them on your system, or leading to zypper dup moving more packages to those OBS repos than a sensible user would be comfortable with
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'.
The risks are less today than they ever were with the 13.x series, but the risks are still there, and people need to be wary to mitigate them. -- 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
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? Regards Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Martin Wilck <mwilck@suse.com> [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
On Mon, 2017-01-02 at 11:50 -0500, Patrick Shanahan wrote:
* Martin Wilck <mwilck@suse.com> [01-02-17 11:20]:
On Wed, 2016-12-28 at 23:59 -0500, Felix Miata wrote:
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.
From my understanding of this thread, "zypper dup --no-allow-vendor- change" would be the recommended way to update for novice users, in particular if non-standard repos such as packman are active. If that's true, it makes sense to make it the default. Novice users can't be expected to read through and understand the Wiki before doing updates. Users with different preferences can still set the option back to false. RPM update mechanism can make sure that the default doesn't change silently for running systems.
It took myself (new to TW but not to Linux) 6 months and this thread to even find out about "solver.dupAllowVendorChange". Regards, Martin PS: Funny, my personal preference is to allow vendor change on update and disallow it on dup, quite contrary to the current default. -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- 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
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.
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
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
On Monday, 2 January 2017 21:39:10 CET Andrei Borzenkov wrote:
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) in 30seconds i have changed my mind! Even having different settings on TW it woud FUNCTIONALY do exactly what the user wanted on both leap and TW. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-12-28 11:16, 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.
I agree. ...
[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]
I do not recommend TW to noobs. :-| -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Op woensdag 28 december 2016 15:14:31 CET schreef Carlos E. R.:
On 2016-12-28 11:16, 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.
I agree.
...
[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]
I do not recommend TW to noobs. :-|
After a recent discussion: I wouldn't use the word 'noobs'. -- 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
* Knurpht - Gertjan Lettink <knurpht@opensuse.org> [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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-12-28 16:07, Knurpht - Gertjan Lettink wrote:
Op woensdag 28 december 2016 15:14:31 CET schreef Carlos E. R.:
On 2016-12-28 11:16, nicholas wrote:
[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]
I do not recommend TW to noobs. :-|
After a recent discussion: I wouldn't use the word 'noobs'.
Why? :-? He used it on himself. I have no idea what is wrong with the word :-? - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlhj3BsACgkQja8UbcUWM1wqwQD9EeBknDacV6JscXFrPj+J4Q6R cF3IRG++QrEAR4/Pj48A/Rvm31BCqyidTjZ0lQzTIUNs4G5Pdk/qrt2bNxjcik/+ =YG+Z -----END PGP SIGNATURE----- -- 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:16 AM, 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.
Forums are filled with confusion over the update process e.g. https://forums.opensuse.org/showthread.php/517451-Differnce-between-zypper-u...
I have seen other suggestions of (including by forum global moderator) 'zypper up' mostly, 'zypper dup' occasionally, this is without clarfying to disable extra repos. https://forums.opensuse.org/showthread.php/504212-I-get-no-updates-to-Tumble...
there are also MANY implicit postings of problems suggesting the OP is not even aware of the issues.
The current update process would appear: non-evident (not communicated, ambiguous (when to up/dup?), non deterministic (its ok to get out of sync sometimes?), error prone (new user forgets to disable extra repos), time consuming mess.
in fact, do zypper up/dup really make sense conceptually or functionally to a rolling distribution?
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 have 'alias tup=sudo zypper dup --no-allow-vendor-change' in .bashrc - Is the dup default of allow-vendor-change really required for leap upgrade?
[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]
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. Ken Schneider -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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". -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [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
participants (22)
-
Aleksa Sarai -
Andrei Borzenkov -
Anton Aylward -
Bernhard M. Wiedemann -
Carlos E. R. -
Daniele -
Felix Miata -
H.Merijn Brand -
Jan Engelhardt -
Johannes Kastl -
Ken Schneider -
Ken Schneider - Factory -
Knurpht - Gertjan Lettink -
Luiz Fernando Ranghetti -
Martin Wilck -
nicholas -
nicholas cunliffe
-
Oliver Kurz -
Patrick Shanahan -
Richard Brown -
Robert Kaiser -
Stefan Seyfried