So when will openSUSE get an easier upgrade process?

[robin_listas]

On 2013-11-30 13:56, wolfi323 wrote:
>
> robin_listas;2603824 Wrote:

>> Careful, because you have to disable all the other repos, like packman.
>> As it is, it can be dangerous.
>>
> Correct, and that’s exactly the main problem.
> How should any automatic distribution upgrade tool know, which of the
> 1000s of repos are safe and which are not.

Removing all of them, then adding the four that are needed

> I merely wanted to demontrate that it is not hard and painful to do the
> actual upgrade.

Right.

> A safer version of the script:
>
> Code:
> --------------------
> #!/bin/bash
> zypper mr -da
> zypper ar http://download.opensuse.org/distribution/13.1/repo/oss/ repo-oss
> zypper ar http://download.opensuse.org/distribution/13.1/repo/non-oss/ repo-non-oss
> zypper ar http://download.opensuse.org/update/13.1/ repo-update
> zypper ar http://download.opensuse.org/update/13.1-non-oss/ repo-update-non-oss
> zypper dup
>
> --------------------
>
> This diables all repos and adds the 4 standard ones for the new
> version.

That’s right.

> Now change that to take the new version as parameter and you have a
> minimal universal upgrade script…

You would have to consider that some versions back, there was only one
update repo. It may be possible that some future version adds or remove
something else. So you would have to do a long “case” and do the
specific changes for each release.

Also you would need the user to read and accept the release notes of
each release, because each time you have to do something different,
something else.

Also, there is the recommendation to update the zypper stack first,
separately. Another one is to ensure you are in runlevel 3, or
alternatively using tmux (and what to do if X crashes and not recover,
how to attach again in text mode to the tmux session)

Another recommendation is to download everything in advance, which also
has to ensure you have the required disk space. If there is not, then
you can not download in advance, but as needed, which is more dangerous
(network stack could crash).

Not rocket science, but if you say that you can do the upgrade
automatically, you really need to consider everything. >:-))

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

[robin_listas]

On 2013-11-30 14:46, hcvv wrote:
>
> While I liike all the nice scripts shown here, IMHO the problem with
> this or any other script is that you can not let them loose on the
> uninitiated. They will use it with e.g. parameter 14.2 long after the
> devs decided to change the word “distribution” in the path to “distro”,
> or a more recent change, add a repo (the update-non-oss). The devs will
> feel free to do so without further notice because they will reckon this
> as being internal to what they offer. As usual, it is easier to write a
> script then to maintain it and keep it up-to-date.

Absolutely!

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

[wolfi323]

@robin_listas

You would have to consider that some versions back, there was only one
update repo. It may be possible that some future version adds or remove
something else. So you would have to do a long “case” and do the
specific changes for each release.

Also you would need the user to read and accept the release notes of
each release, because each time you have to do something different,
something else.

I don’t want/need such a script, as I already stated.
And I said that it won’t consider any possible circumstances.

If somwbody wants to do something like that, this could be a starting point.

Also, there is the recommendation to update the zypper stack first,
separately. Another one is to ensure you are in runlevel 3, or
alternatively using tmux (and what to do if X crashes and not recover,
how to attach again in text mode to the tmux session)

Right. But adding a “zypper in zypper” is not difficult either.

Another recommendation is to download everything in advance, which also
has to ensure you have the required disk space. If there is not, then
you can not download in advance, but as needed, which is more dangerous
(network stack could crash).

Zypper does download before installing by default, at least since quite a while.

Not rocket science, but if you say that you can do the upgrade
automatically, you really need to consider everything. >:-))

I didn’t say that, and I don’t find it necessary.

Also there’s YaST Wagon already, which in the end just updates the Software stack and then does the upgrade.
So in essence it’s a GUI frontend to “zypper in zypper && zypper dup”.

Again, my point was not to present a perfect upgrade script, but just to show that doing the upgrade is not so difficult that you need a script/application for it.

And at least that showed that it would be not so easy to create and maintain an “official” application for that.
And again, IMHO there’s no point in trying to either.

[wolfi323]

@robin_listas

On 2013-11-30 13:36, wolfi323 wrote:
>
> Miuku;2603828 Wrote:
>> Out of curiosity, why is that?
>>
>> I did a similar upgrade like this, although a slightly different and I
>> had no issues whilst all the gstreamer and other packages were upgraded
>> nicely from Packman as it all worked just ‘fabulously’.
> Yes, Packman should work without problems.

It is not the tested path by the developers. Zypper posts a severe
warning when you do it. If it works, you were lucky.

Have a look at what packages are in the Packman repo, and you will see that it will work. You don’t have to be lucky.
Zypper posts a severe warning because it is not safe in every possible case. (btw, it also posts this warning if you only have the 4 standard repos)
You should of course know what you’re doing when you run “zypper dup”, especially when you use lot of unofficial non-standard repos.

[consused]

@Jonathan_R

consused, there is a way to accomidate the OP and still have it the way most of us like it. A script could do that as nrickert suggested is totally feasable. One could package it as an rpm. An option could be included so that it would ask if the user would like to do a rolling update release.

Yes. I had read the nrickert reply - at least a workaround or at best a short-term solution. However, it didn’t address the question in the title. Not sure anyone here knows if or when, so I attempted to explain the circumstances in a follow-up reply, but I hadn’t read all the intervening posts. I now see there were some of the usual hand-off’s.

The OP, from what I read, isn’t asking so much as to why we don’t, and certainly not looking for excuses or “reasons” why it isn’t done…

That’s one interpretation. Another is that the questioner deserves to know why it might not appear as a feature of the distro any time soon. If one is serious about getting a requirement accepted by any development project, it’s important to understand the objections that could be raised.

[john_hudson]

Going back to the OP, having tried the zypper dup route for the first time with 13.1, copying and pasting four command lines into the console and answering yes or no to a few prompts is certainly less trouble than checking the time zone, putting in user names and passwords, re-enabling the repositories, downloading the other software I use and doing the one click multimedia install.

Because I’ve never tried the equivalent on another distro, I don’t know how much easier it would be than pasting in four command lines and answering a few questions (zypper told me to get rid of only two repositories, one of which had been superseded and the other of which was unimportant; so I haven’t had to re-enable any repos).

[MadmanRB]

Well Zypper duping is overall easy, I just wish it was more gui friendly for the commandline wary (newbies mainly)

[senthilp_ateam]

Who told upgrading is painful in openSUSE? I easily upgraded from 12.3 version to 13.1 version :). I think upgrading process is not that complicated. Check out the link.

How To Upgrade From openSUSE 12.3 To openSUSE 13.1 | Unixmen

[conram]

@senthilp_ateam

Who told upgrading is painful in openSUSE? I easily upgraded from 12.3 version to 13.1 version :). I think upgrading process is not that complicated. Check out the link.

How To Upgrade From openSUSE 12.3 To openSUSE 13.1 | Unixmen

Yes it is easy, the only difference I see against a new installation is
system-update takes more time to finish than a new install.

To add you can even customize how you update the applications to your liking
I have done this in one of my machine while updating it from 12.3 to 13.1
and this one reduces the time spent to upgrade.

[consused]

@senthilp_ateam

Who told upgrading is painful in openSUSE?

Nobody did really. The OP was interested in “an easier” process for users new to linux, as provided by some other distros.

The zypper process is relatively easy. If there is to be any resulting pain, it’s usually self-inflicted by upgrading with an unnecessarily complicated repo configuration.

[wolfi323]

JFYI: Sebastian Siebert, the guy who works on the fglrx drivers for openSUSE, has indeed written an upgrade script.
See here: openSUSE – Upgrade der Distribution mit einem Skript

Unfortunately the page is german only, but here’s google translator’s english version that should at least be comprehensible I think:
Google Übersetzer

[PiElle]

In my opinion it’s better a fresh new install, keeping the old home partition …

[MadmanRB]

@PiElle

In my opinion it’s better a fresh new install, keeping the old home partition …

Yeah but there is a bit of a hassle reinstalling codecs and apps

[hendersj]

On Thu, 26 Dec 2013 15:56:01 +0000, MadmanRB wrote:

> PiElle;2611145 Wrote:
>> In my opinion it’s better a fresh new install, keeping the old home
>> partition …
>
> Yeah but there is a bit of a hassle reinstalling codecs and apps

Adding the repo isn’t really that big of a deal, though.

It is, however, important to back up configuration items - one I missed
on my upgrade to 13.1 was cron jobs.

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C