updating tumbleweed - best practices

classic Classic list List threaded Threaded
73 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

updating tumbleweed - best practices

nicholas cunliffe
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-up-and-zypper-dup

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-Tumbleweed

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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

Aleksa Sarai
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-up-and-zypper-dup

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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

Richard Brown
In reply to this post by nicholas cunliffe
On 28 December 2016 at 10:16, nicholas <[hidden email]> 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-up-and-zypper-dup
>
> 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-Tumbleweed
>
> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

Richard Brown
In reply to this post by Aleksa Sarai
On 28 December 2016 at 10:48, Aleksa Sarai <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

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

> On 28 December 2016 at 10:48, Aleksa Sarai <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

nicholas cunliffe
On 28 December 2016 at 13:23, nicholas <[hidden email]> wrote:

> On Wednesday, 28 December 2016 10:57:29 CET Richard Brown wrote:
>> On 28 December 2016 at 10:48, Aleksa Sarai <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

Luiz Fernando Ranghetti-2
2016-12-28 10:52 GMT-02:00 nicholas cunliffe <[hidden email]>:

> On 28 December 2016 at 13:23, nicholas <[hidden email]> wrote:
>> On Wednesday, 28 December 2016 10:57:29 CET Richard Brown wrote:
>>> On 28 December 2016 at 10:48, Aleksa Sarai <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

nicholas cunliffe
On Wednesday, 28 December 2016 11:43:42 CET you wrote:

> 2016-12-28 10:52 GMT-02:00 nicholas cunliffe <[hidden email]>:
> > On 28 December 2016 at 13:23, nicholas <[hidden email]> wrote:
> >> On Wednesday, 28 December 2016 10:57:29 CET Richard Brown wrote:
> >>> On 28 December 2016 at 10:48, Aleksa Sarai <[hidden email]> 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
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

Carlos E. R.-2
In reply to this post by nicholas cunliffe
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)


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

H.Merijn Brand
In reply to this post by Luiz Fernando Ranghetti-2
On Wed, 28 Dec 2016 11:43:42 -0200, Luiz Fernando Ranghetti
<[hidden email]> wrote:

> 2016-12-28 10:52 GMT-02:00 nicholas cunliffe <[hidden email]>:
> > On 28 December 2016 at 13:23, nicholas <[hidden email]> 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_Tumbleweed
 20 Yes  99  No rpm-md Postgres-TW       http://download.opensuse.org/repositories/server:/database:/postgresql/openSUSE_Tumbleweed
 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/

attachment0 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

nicholas cunliffe
(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 <[hidden email]> wrote:

> On Wed, 28 Dec 2016 11:43:42 -0200, Luiz Fernando Ranghetti
> <[hidden email]> wrote:
>
>> 2016-12-28 10:52 GMT-02:00 nicholas cunliffe <[hidden email]>:
>> > On 28 December 2016 at 13:23, nicholas <[hidden email]> 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_Tumbleweed
>  20 Yes  99  No rpm-md Postgres-TW       http://download.opensuse.org/repositories/server:/database:/postgresql/openSUSE_Tumbleweed
>  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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

Carlos E. R.-2
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)


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

Patrick Shanahan-2
In reply to this post by Luiz Fernando Ranghetti-2
* Luiz Fernando Ranghetti <[hidden email]> [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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

Anton Aylward-2
In reply to this post by Richard Brown
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

Knurpht-openSUSE
In reply to this post by Carlos E. R.-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

Ken Schneider
In reply to this post by nicholas cunliffe
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-up-and-zypper-dup
>
> 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-Tumbleweed
>
> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

Ken Schneider
In reply to this post by Aleksa Sarai
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-up-and-zypper-dup 
>>
>
> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

Patrick Shanahan-2
In reply to this post by Knurpht-openSUSE
* Knurpht - Gertjan Lettink <[hidden email]> [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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

Knurpht-openSUSE
In reply to this post by nicholas cunliffe
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: updating tumbleweed - best practices

Carlos E. R.-2
In reply to this post by Knurpht-openSUSE
-----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: [hidden email]
To contact the owner, e-mail: [hidden email]

1234