Feature changed by: Oliver Kurz (okurz) Feature #313441, revision 40 Title: Easier distribution upgrade openSUSE Distribution: New Priority Requester: Desirable Requested by: Mário Castanheira (speccyman) Partner organization: openSUSE.org 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). Relations: - As easy as 1, 2, 3… (url: http://morice.ipsquad.net/blog/?p=29) - fate for SLE migration feature (url: https://fate.suse.com/315161) - rejected: yast2 wagon as gui (feature/id: 310405) - online upgrades with user notification (feature/id: 308351) - Debian-like dist-upgrade live system full version upgrade (feature/id: 305634) Use Case: 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! Business case (Partner benefit): openSUSE.org: 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. Discussion: #1: Sławomir Lach (lachu) (2012-05-02 22:04:14) As I remember, there exist a Yast module to do that. #2: Mário Castanheira (speccyman) (2012-05-02 23:35:32) (reply to #1) 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 :) #3: phil osophe (posophe) (2012-10-04 14:41:39) Yes but there s annother advantage of easy dist-upgrade like ubuntu, it removes unmaintained anymore packages or replacement packages #4: Mário Castanheira (speccyman) (2012-10-08 17:12:00) (reply to #3) 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). #5: Gavin S (gav616) (2012-10-09 16:34:34) 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. #6: Simone Ramacci (simosito) (2012-10-15 12:22:00) 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). #7: phil osophe (posophe) (2012-10-18 10:05:18) (reply to #6) 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... #8: Mário Castanheira (speccyman) (2012-11-23 20:53:50) (reply to #6) 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. #9: Narayansamy S (vazhavandan) (2012-11-30 18:07:15) 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.. #10: Mário Castanheira (speccyman) (2012-12-05 14:38:09) (reply to #9) 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 :) #11: phil osophe (posophe) (2012-12-06 11:02:26) (reply to #10) And the team take care for it doesn't append. Why don't simplify the life of users when we can ? #12: Lukas Krejza (gryffus) (2013-01-02 14:58:44) 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? #13: Mário Castanheira (speccyman) (2013-01-03 15:30:50) (reply to #12) 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, ...) #14: Paul Parker (paulparker) (2013-03-02 05:48:10) 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. #15: phil osophe (posophe) (2013-03-03 15:13:31) (reply to #14) 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. #16: Mário Castanheira (speccyman) (2013-03-13 17:02:37) (reply to #15) 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 :) #17: Mário Castanheira (speccyman) (2013-03-25 18:03:12) I've found a post written by Jean-Nicoloas Artaud called " As easy as 1, 2, 3… (http://morice.ipsquad.net/blog/?p=29) " 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"?) #18: Denisart Benjamin (posophe) (2015-01-19 16:18:25) Maybe we could have a look on calamares too, which seems promiseness #19: Mário Castanheira (speccyman) (2015-01-20 14:43:14) (reply to #18) 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? + #20: Oliver Kurz (okurz) (2017-01-10 09:39:28) + 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_wo... + [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_wo... + [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_wo... + and the zypp repos are backed up: https://github.com/yast/yast-migration/blob/master/src/lib/migration/main_wo... + … [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....) + [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) -- openSUSE Feature: https://features.opensuse.org/313441