Home_greyopenFATE - openSUSE feature tracking > #313441
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Easier distribution upgrade

Feature state

openSUSE Distribution
New

Description

An easy way to allow users to make upgrades (e.g.: changing from version 12.1 to version 12.2) as easy as they can in Ubuntu - using a GUI.

Something like a notification whit a button to perform the upgrade whit just one-click, instead of having to deal whit the work of manually disable all of the repositories, update them manually, open the terminal and finally make a "zypper dup" .

In short, this would perform the following actions:

  1. Notify there is a new version of OpenSuse, asking if the user wants to upgrade.
  2. If the user accepts it should upgrade all the repos (If possible. If not leave them deactivated)
  3. Make a "zypper dup"
  4. And finally make a computer reboot

Would be good if all this would be automatic (maybe even integrate it in Yast or in the new Software Center - Apper, apparently, already supports this feature in Ubuntu).

User benefit:

The benefit for the user is that this feature will encourage users to keep their distro in it's lastest version, even if they don't understand much about computers!

This will bring them a greater experience in opensuse since they will have access to stable and newest features and also many other improvements.

It's also because it's something all Ubuntu users keep saying it's one of their loved features.

Relations

Usecase

User gets notified that there's a new version of opensuse available and it is asked if he wishes to upgrade. If he selects "upgrade" the system should ask for permissions and then start upgrading itself. (pretty much like in ubuntu). Nothing else required!

Testcase

1. Given a clean installed system from an older version, e.g. openSUSE Leap 42.1,
And all available updates from the update repositories have been installed
When the next distribution version is available, e.g. openSUSE Leap 42.2,
Then a notification pops up after a "reasonable time" offering the user to upgrade
And an upgrade can be completed successfully automatically following a GUI approach (e.g. first applying "zypper patch --updatestack-only")
2. Given an old system as in 1. but with no updates installed (e.g. only installed from DVD, no updates after that)
When the next distribution is available
Then an upgrade can be completed successfully (by applying updates first, then upgrading)

3. Given a system as in 1
But with 3rd party repositories enabled
When the upgrade assistant is started
Then the user is informed about 3rd party repositories (refuses to update OR offers to disable all and warn the user when continuing)

Discussion


icons/user_comment.png S. L. wrote: (5 years ago)

As I remember, there exist a Yast module to do that.

icons/user_comment.png M. C. wrote: (5 years ago)

well, if you're referring to YaST Online Update (YOU), as far has i know, it can't do upgrades unless you manually deactivate some of your repos and update others to match the repos of the new version. Only then you can upgrade.

Those manual changes is what this feature is trying to avoid :)

icons/user_comment.png p. o. wrote: (5 years ago)

Yes but there s annother advantage of easy dist-upgrade like ubuntu, it removes unmaintained anymore packages or replacement packages

icons/user_comment.png M. C. wrote: (5 years ago)

I think OpenSuse is already able to do this. I think it's an Yast Option called "CleanUp when Delecting Packages" (don't know if "System Verification Mode" has anything to do whit it as well).

icons/user_comment.png G. S. wrote: (5 years ago)

non rolling release distro's always recommend a fresh install mainly because of changing config files and defaults/philosophy changes. Rolling distro's try to combat this with automatically re-writing those files or diff'in them to the user, it's messy. Also how do you "connect" with the users to remove unmaintained software or "push" better solutions (new filesystems, better security practices).

I think an awesome idea would be, to some how integrate the New release DVD installer to the actual Upgrade process (dump it in RAM??).
This could provide an initial backup options for your home folder and important yast data. Then it could just carry on as a normal DVD install, offering all the new features, security and up-to-date philosophy.

icons/user_comment.png S. R. wrote: (5 years ago)

To be honest I was never able to successfully upgrade any Ubuntu version, that is one of the reasons I switched to OpenSUSE.

I did a dist upgrade to the current version and I had no problems at all. In fact it also fixed a problem I had with KDE.

As far as I can tell my Ubuntu problems were caused by trying to upgrade an LTS to a non-LTS, with a distro that radically changes every 10 seconds.

With SUSE we don't usually have this problem, because of the shorter life cycle and more gradual introduction of new features.

This said, why don't we change the description to something like:

«Allow user to be notified about new distro version, and to upgrade from graphical tool OR DVD, after choosing whether to back-up /home/$USER or not»

Thus providing both a (I hope) better version of the Ubuntu way (not that we always have to do like they do) and Gavin S' way (I think Windows tries to do that disc approach, but I've never tried).

icons/user_comment.png p. o. wrote: (5 years ago)

Ubuntu way is not the main subject of this user request but only a graphical or command line tool whose do what user will make for upgrade opensuse :
Changing Suse repo, zypper up,etc
With a cli we can purpose replacements, remove obsoletes and unmaintained softs. It's difficult at least to manage the distro because a newer version is a pack of packages. Then with a update manager we could manage what must be added, removed...

icons/user_comment.png M. C. wrote: (5 years ago)

What i thought was actually what p.o. already said:

A graphical tool that would:

1.Notify there is a new version of OpenSuse, asking if the user wants to upgrade.
2.If the user accepts it should upgrade all the repos (If possible. If not leave them deactivated)
3.Make a "zypper dup"
4.And finally make a computer reboot

This could be integrated into Apper or the new Software Center and should definitely be integrated into our beloved YAST.

icons/user_comment.png N. S. wrote: (5 years ago)

I think users should really come back to opensuse.org and read the release notes and then visit forums and get clarifications and then perform upgrade. Blind up gradation may cause lot of issues like hardware incompatibilities etc..

icons/user_comment.png M. C. wrote: (5 years ago)

Well, the notification could also bring the link to the release notes, where issues could also be listed. ;)

I have been upgrading since the cl feature became available and never had any issues (which does not mean they are inexistent, just that I never had problems whit it :)

icons/user_comment.png p. o. wrote: (5 years ago)

And the team take care for it doesn't append. Why don't simplify the life of users when we can ?

icons/user_comment.png L. K. wrote: (5 years ago)

In past there was yast module doing exactly what you request named "wagon".
I wonder what has happened to it and why it has been abadoned?

icons/user_comment.png M. C. wrote: (5 years ago)

Wagon was not abandoned and is still available in OpenSuse software portal (see http://software.opensuse.org/package/yast2-wagon ).

However Wagon is a Migration tool for Service Packs and, as far as i can tell, it is not designed to do Distro Upgrades. So, it does not do what is requested (E.g.: it does not automatically updates the repos, does not notify the user, ...)

icons/user_comment.png P. P. wrote: (5 years ago)

Am a NON-Technical user, problems depend greatly on where you view them from...

Self recommends other NON-Technicals upgrade from one version to next using clean install rather than using
zypper dup

Clean install reduces significantly the opportunity for left-over pieces to create not so easy to resolve issues.

Previously learnt just how hard locating the source of glitches whilst not critical may be to resolve, even with excellent technical support available from SLED/SLES.

icons/user_comment.png p. o. wrote: (5 years ago)

The goal is to prevent/avoid these cases, not to make dist upgrade less easy.
In general, repos upgrade works correctly. It is not user-friendly, that why users request it.

icons/user_comment.png M. C. wrote: (4 years ago)

Also, the feature could be Off by default and be enabled in YaST only if a user wishes it (could even have a message for alerting possible troubles)

Anyway, if a upgrade causes problems, one can always make a fresh install to (most probably) solve it :)

icons/user_comment.png M. C. wrote: (4 years ago)

I've found a post written by Jean-Nicoloas Artaud called "
As easy as 1, 2, 3… " that really makes one see how ridiculously easy it is to make an upgrade on openSuse!!!

So, basically the idea of this feature is to have an alert about a new version and when one click "upgrade" it would do this steps whit a GUI ;)

(How about changing this feature title to "Even Easier Upgrade"?)

icons/user_comment.png D. B. wrote: (3 years ago)

Maybe we could have a look on calamares too, which seems promiseness

icons/user_comment.png M. C. wrote: (3 years ago)

If you're refering to calamares.io It does seems cool, however the question is: would Calamares solve the problem/feature enhancement proposed?

In other words: would Calamares notify the user about a new version of the OS and allow the upgrade to that same version (upgrade repos from 13.2 -> 13.3 and perform the OS upgrade) whitout making the (noob) user get to the konsole?

icons/user_comment.png O. K. wrote: (10 months ago)

As yast-wagon is obsoleted the feature will not be feasible to be implemented based on yast-wagon: https://github.com/yast/yast-wagon
From IRC-discussion on irc://chat.freenode.net/yast:
There is "yast2 migration" for SLE and I was wondering about the applicability to openSUSE. yast2-migration needs SCC, it provides the update repos and migration paths so for openSUSE that part would need to be rewritten.
yast2-migration was mainly designed by lslezak.

[10 Jan 2017 09:34:30] <ancorgs> lslezak: would it be possible to have a SCC-less mode that calculate those for openSUSE?
[10 Jan 2017 09:35:41] <okurz> ok, SCC won't work, of course. I am thinking of something like a simple assistant that guides the user through some steps and not offer as much as SCC and yast migration do but at least give the user some hints if the easy way fails
[10 Jan 2017 09:35:48] <lslezak> yes, that SCC-less mode should be possible

[10 Jan 2017 09:37:45] <lslezak> okurz: with SLE it's simple as normally users have only repos from SCC, with openSUSE users more likely have a bunch of 3rd party repos (e.g. Packman) and that makes troubles...
[10 Jan 2017 09:39:25] <ancorgs> lslezak: well, IIRC the update instructions tell the user to disable 3rd part repos during the process
[10 Jan 2017 09:39:40] <okurz> lslezak: yes, easy way: Disable all and tell the user that he continues on his own responsibility because we can not check dependencies will be properly resolved when 3rd party are enabled
[10 Jan 2017 09:40:24] <okurz> btw, isn't that a potential issue on SLE, too, which could be checked by the migration? E.g. warn and abort if any 3rd party repos are found on SLE. The same detection mechanism then also applies for openSUSE but at least allows to continue on own risk
[10 Jan 2017 09:42:17] <lslezak> okurz: some details: the migration module calls this to add the migration repos from SCC, for openSUSE you would "only" need to reimplennt this call: https://github.com/yast/yast-migration/blob/master/src/lib/migration/main_workflow.rb#L187
[10 Jan 2017 09:42:44] <lslezak> okurz: plus the rollback when migration is aborted or fails: https://github.com/yast/yast-migration/blob/master/src/lib/migration/main_workflow.rb#L182
[10 Jan 2017 09:44:01] <okurz> lslezak: also that part could be done in a more "easy" way but still provide useful for openSUSE: Just don't do rollback, the user is always asked to have a backup … and there are snapper snapshots :-)
[10 Jan 2017 09:46:03] <lslezak> okurz: yes, at the beginning it creates a snapshot https://github.com/yast/yast-migration/blob/master/src/lib/migration/main_workflow.rb#L225 and the zypp repos are backed up: https://github.com/yast/yast-migration/blob/master/src/lib/migration/main_workflow.rb#L148

[10 Jan 2017 09:47:48] <lslezak> okurz: well, instead of the SCC "registration" you need to add the update repositories with the new version, that part is missing
[10 Jan 2017 09:48:34] <lslezak> okurz: however, that SCC part allows addig custom repos, so it could be at least partly (re)used for that

[10 Jan 2017 09:51:49] <lslezak> okurz: um, for adding extra community repos we have this XML: http://download.opensuse.org/YaST/Repos/_openSUSE_Leap_42.2_Default.xml (linked from http://download.opensuse.org/YaST/Repos/openSUSE_Leap_42.2_Servers.xml)
[10 Jan 2017 09:52:12] <lslezak> okurz: we could use something similar for definign the upgrade repositories...
[10 Jan 2017 09:53:52] <lslezak> (BTW the URL is defined in the control.xml: https://github.com/yast/skelcd-control-openSUSE/blob/master/control/control.openSUSE.xml#L95)
[10 Jan 2017 09:55:20] <okurz> lslezak: so no auto-resolution magic from download.o.o but a simple rule in a xml file? Sounds like a safer approach. If there would be any step necessary during the release process I guess lnussel, the Leap RM, would have no problem to ensure that this is done, e.g. as a ticket in https://progress.opensuse.org/projects/opensuse-release-process
[10 Jan 2017 09:57:56] <lslezak> okurz: I'd avoid any auto magic in this case, with a XML file definition we could "enable" the migration when it's really ready and tested (as we do for SLE)
[10 Jan 2017 10:00:53] <ancorgs> lslezak: we should already have a class (or any other abstraction) providing the upgrade repos and all that. With SCC just being a possible backend for that
[10 Jan 2017 10:01:18] <ancorgs> so a bunch of xml stored somewhere would just be another backend
[10 Jan 2017 10:05:50] <lslezak> ancorgs: having another backend in registration would make it too complicated IMHO (SCC needs previous registration, XML files not), the migration just calls the "migration_repos" client from the registratino module, in openSUSE we would just call a different client with a separate implementation (no need to mess the registration module)

icons/user_comment.png F. M. wrote: (10 months ago)

#!/bin/sh
zypper rm biosdevname
zypper -v in zypper libzypp libsolv-tools rpm openSUSE-release
zypper -v in device-mapper dmraid glibc lvm2 multipath-tools mdadm systemd udev

For too long to remember, probably at least 4 years, and on too many installations to track or remember, whilst with no GUI logins running, I've been preceding zypper dup with the above script, first on Factory, later on distribution upgrades and with Tumbleweed. Before starting I make appropriate edits to /etc/zypp/repos.d/, which in most cases does not include removing the usually present optional repos, such as KDE3, Packman and Mozilla. The only time I can remember achieving a less than fully satisfactory result was when I attempted to go directly from i586 13.1 to (x86_64) 42.1RC1, with the primary glitch related to the switch from kernel-desktop to kernel-default. I would hope any "easier distribution upgrade" would not break the consistent success of my upgrade method.

Last change: 6 months ago
Voting
Score: 21
  • Negative: 2
  • Neutral: 4
  • Positive: 23
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint