The idea is about an easy way to allow users to make upgrades (e.g.: changing from one major version like 15.0 to version 15.1) using a GUI and as easy as they can in Ubuntu.

Something like a notification with a button to perform the upgrade with just one-click, instead of having to deal with the terminal, that frights some new users and gives them the sensation of an outdated system.

In short, this would perform the following actions:

- Notify there is a new version of openSUSE, asking if the user wants to upgrade.
- If the user accepts it should make a "zypper --releasever=15.3 dup" (after password...)
- And finally make a computer reboot

This could be integrated in Yast or in Discover.

This, i believe would bring good User benefits such as:

- encourage users to keep their distro in it's lastest version, even if they don't understand much about computers!
- bring them a greater experience in openSUSE since they will have access to stable and newest features and also many other improvements.
- it will end with the disadvantage of one of the most mentioned Ubuntu features.
- it would look more modern

We also, already, had a few implementations in this areas:

- openSUSE Wagon - now deprecated

- Yast-Migration Module - SLE specific that might be able to be adapted

I don't believe there would be much work to this and the benefits would be great... :)

This should be applied to Tumbleweed as well. My idea for tumbleweed being: An option - off by default - to enable auto-upgrade without confirmation.

Would be good to have this feature without the need to register the system anywhere (unlike SUSE).

After some search i discovered someone already had this idea a long time ago (since at least 2012). So I borrowed some text (with a few upgrades) from the OpenFATE feature ( https://features.opensuse.org/313441 ).

Related Links:

https://bugzilla.opensuse.org/show_bug.cgi?id=1201144

https://bugs.kde.org/show_bug.cgi?id=451849

https://hackweek.opensuse.org/21/projects/implement-gnome-softwares-distribution-upgrade-in-leap

Looking for hackers with the skills:

upgrade

This project is part of:

Hack Week 14 Hack Week 15 Hack Week 16 Hack Week 17 Hack Week 18 Hack Week 19 Hack Week 20 Hack Week 21 Hack Week 22

Activity

  • over 1 year ago: FabioMux joined this project.
  • over 1 year ago: okurz liked this project.
  • over 2 years ago: fbonazzi liked this project.
  • over 2 years ago: JonathanKang disliked this project.
  • over 2 years ago: m_vanderwulp liked this project.
  • over 2 years ago: QuaTran liked this project.
  • over 2 years ago: ismaell liked this project.
  • over 3 years ago: cdywan liked this project.
  • over 3 years ago: IGonzalezSosa liked this project.
  • over 3 years ago: alarrosa liked this project.
  • over 3 years ago: alarrosa disliked this project.
  • over 3 years ago: dfaggioli liked this project.
  • over 3 years ago: ybonatakis liked this project.
  • over 4 years ago: PSuarezHernandez liked this project.
  • over 4 years ago: SLindoMansilla liked this project.
  • over 4 years ago: deneb_alpha left this project.
  • over 4 years ago: juliogonzalezgil liked this project.
  • over 4 years ago: xiaoguang_wang liked this project.
  • over 4 years ago: deneb_alpha joined this project.
  • over 4 years ago: deneb_alpha liked this project.
  • over 4 years ago: fos liked this project.
  • over 4 years ago: gboiko liked this project.
  • over 5 years ago: ikapelyukhin liked this project.
  • over 5 years ago: a_faerber liked this project.
  • over 5 years ago: aspiers liked this project.
  • All Activity

    Comments

    • pluskalm
      over 7 years ago by pluskalm | Reply

      afaik correct spelling openSUSE

      • maverick74
        over 7 years ago by maverick74 | Reply

        Corrected ;)

    • mwilck
      over 7 years ago by mwilck | Reply

      Would it make sense to combine this with an offline update approach (similar to FedUp on Fedora) to avoid crashes or other trouble that may happen during live updates?

      • maverick74
        over 7 years ago by maverick74 | Reply

        (Reply bellow)

    • maverick74
      over 7 years ago by maverick74 | Reply

      Yes, i believe it would make a lot of sense. As long as it's not mandatory, of course.

      It could be the default configuration, but if one (really) wants to take the risk it should be able to do live upgrades as well.

      (Anyway, isn't this the default behavior already? When one does a "zypper dup" it first downloads all the packages and only then performs the upgrade)

    • maverick74
      over 7 years ago by maverick74 | Reply

      I've been thinking about this and i would like to add that this applied to Tumbleweed would also be gold (my idea for tumbleweed being actually an option - off by default - to enable auto-upgrade without confirmation).

    • mbrugger
      almost 7 years ago by mbrugger | Reply

      This is great idea. Actually the update problem is one why I hesitate to tell non-technical people to use openSUSE. Up to now Ubuntu does a much better job there.

    • maverick74
      almost 7 years ago by maverick74 | Reply

      I just found this: https://progress.opensuse.org/issues/20910

      Not sure if this is related, however...

    • mwilck
      almost 7 years ago by mwilck | Reply

      I wonder if we need some offline update tool such as dnf system-upgrade (formerly FedUp) on Fedora.

    • lnussel
      about 6 years ago by lnussel | Reply

      I'd actually like to get Leap into SCC so we can reuse the existing yast migration module, ie no separate code to maintainer for openSUSE. The part about notifying the user of a distro upgrade would still need to be implemented somehow eg via packagekit and the updater applets.

      • maverick74
        over 5 years ago by maverick74 | Reply

        Hi. Are there any good news on this for 15.1?

        (or any news at all?) add-emoji

    • JonathanKang
      over 5 years ago by JonathanKang | Reply

      This can be implemented in GNOME Software and PackageKit.

      1. Several zypp backend method are missing in PackageKit to preform related actions.

      2. GNOME Software can upgrade the system with just a few clicks(this works in Fedora, which has proper PackageKit support).

      • maverick74
        over 5 years ago by maverick74 | Reply

        I think Discover also supports it, as well as YaST thru the Online Migration module...

        I really don't think there would be much work to do on this, specially when compared to other projects, but after a few years we still don't have this feature in openSUSE, which i believe is a last-missing-block. Still, no one picks this up :(

    • fschnizlein
      over 5 years ago by fschnizlein | Reply

      Hi I added recently added Leap support to SCC and I thought would be a nice to have the migrations also there. Since SCC already supports complex migrations from one to another product adding migrations for Leap shouldn't be a huge problem. I think this could be done as a hackweek project.

      • maverick74
        over 5 years ago by maverick74 | Reply

        That's GREAT!!!

        2 questions, however:

        1.Is Tumbleweed also supported? 2.Are we required to register or is it available without registration?

      • ikapelyukhin
        over 5 years ago by ikapelyukhin | Reply

        Registering openSUSE to SCC is kinda meh unless you actually plan to migrate it to SLES. However, I think it would be relatively trivial to re-implement the migration API endpoint as a stand-alone daemon working on localhost.

    • fschnizlein
      over 5 years ago by fschnizlein | Reply

      How about implement it like this:

      • Provide a API (which requires no authentication at all) which lists all possible migrations for a given openSUSE CPE This could be provided for example by SCC and proxied to the opensuse.org domain
      • Add support for this to the SUSEConnect library which is already used by zypper migration and yast2-migration
      • Update/Write a good documentation for the openSUSE wiki

      Why I would do it like this:

      The infrastructure with the data is already their and maintained. Implementing another way, might be faster and more easy but I'm a little bit afraid, nobody is maintaining the new solution. On the other hand SCC is already in place. With adding Leap -> SLES migration the openSUSE products are already in the system, adding the migration path from Leap -> Leap or Leap -> Tumbleweed is no much more effort and @lnussel already has to make sure new versions get added. By using the already existing client solutions like yast2-migration and zypper migration we get two client applications which server both a GUI migration application and a already working zypper plugin.

      What do you think? @maverick74 and @ikapelyukhin?

      • maverick74
        over 5 years ago by maverick74 | Reply

        I love the idea! :)

        I have just one question: in the tumbleweed case, could it be used to upgrade (say for e.g.:) from Tumbleweed 20190616 -> Tumbleweed 20190618 ?

        • fschnizlein
          over 5 years ago by fschnizlein | Reply

          From my point of view both versions are in the end the same product release. I would just create Tumbleweed without dates as product and allow users to migrate from Leap to Tumbleweed and not from one snapshot to another.

          • maverick74
            over 5 years ago by maverick74 | Reply

            It does make sense the way you put it!

            I'm totally in agree with your idea! :)

      • maverick74
        over 5 years ago by maverick74 | Reply

        @fschnizlein Let me ask another question:

        In the Leap case, will user get notified that a new version is available?Or that is not in the scope of this project?

        Thank you. Happy hackweek :)

    • ikapelyukhin
      over 5 years ago by ikapelyukhin | Reply

      I've put together opensuse-migration prototype -- it's a bit rough around the edges, but it does what I expect it to do. Give it a try, tell me what you think (via email or Github issues) :D

    • maverick74
      over 4 years ago by maverick74 | Reply

      Just an update:

      ikapelyukhin approach did not have any GUI and there is none planed.

      Also, i don't know if his implementation ever moved into the https://github.com/openSUSE/ namespace or if it just ended up being achieved.

      @ikapelyukhin , can you please bring some more light into the subject about the state of the project? Tks

    • lkocman
      over 4 years ago by lkocman | Reply

      There is a brand new tool to migrate any rhel-like system to RHEL. Perhaps you could inspire there. https://www.redhat.com/en/blog/convert2rhel-how-update-rhel-systems-place-subscribe-rhel?sccid=701f2000000tyBtAAI&fbclid=IwAR0WsT4yFNi3ovbpStKkmfTEgCxtqRiX-wJ-Sp0GMeN2QqVS5cAdSY7E

      Also have a look at the app migration (the web part)

      https://www.redhat.com/en/blog/whats-new-red-hat-application-migration-toolkit-42-including-oraclejdk-openjdk-migration

    • Pharaoh_Atem
      over 4 years ago by Pharaoh_Atem | Reply

      I've actually gotten pretty far in implementing something like this using dnf system-upgrade when rpm-repos-openSUSE-Leap is installed.

      Steps to try it:

      1. Install the rpm-repos-openSUSE-Leap package
      2. Install dnf and dnf-plugin-system-upgrade
      3. Run dnf system-upgrade --releasever 15.2 download
      4. Run dnf system-upgrade reboot

      Alternatively, you can install rpm-repos-openSUSE-Tumbleweed and use that to upgrade from Leap to Tumbleweed. add-emoji

    • maverick74
      over 3 years ago by maverick74 | Reply

      Things have gotten even simplier and now we just need just to run

      1. zypper --releasever=15.3 ref

      2. zypper --releasever=15.3 dup

      But there's still no official notification about new versions neither a Wizard GUI fot the upgrade...

    • ancorgs
    • cdywan
      over 3 years ago by cdywan | Reply

      Is there a plan for this hackweek? What's the current status? I love the idea of easy upgrades but there's so many different projects mentioned in comments...

      • maverick74
        over 3 years ago by maverick74 | Reply

        Nah... there has been a couple of iniciatives about this - some closer to the original idea, others not that quite. But there's never has been anything done that has been accepted into the main project.

        That's why i keep this thing open...

        Things have improved over (this many years) however.

        We are now able to use a simple "zypper releasever=15.3 dup" that will upgrade the repos and perform the upgrade - which is nice but...

        We still have no Notification when there's a new version available and no way to perform it without getting our fingers into the terminal.

        And that's the major idea: something like Ubuntu/Windows/MacOS that, when a new version of the OS is out, the user get's notified and with a simple button click (and password, naturally) he can perform the upgrade to the new version without having to type into the Terminal/konsole...

      • maverick74
        over 3 years ago by maverick74 | Reply

        Also, in case you missed it, ikapelyukhin put up a good implementation of this (with no GUI or notification at the time, however)... but interest from the openSUSE team was apparentely...... none... :(

        Issue link

    • m_vanderwulp
      over 2 years ago by m_vanderwulp | Reply

      We are now able to use a simple "zypper releasever=15.3 dup" that will upgrade the repos and perform the upgrade

      Well, that "releasever" system is broken in the 15.3 to 15.4 upgrade ... see my description of step 6 at https://en.opensuse.org/SDB:SystemupgradetoLeap15.4#6.Refreshwiththenew_repos:

      This is caused by the relocation of some repos as follows:

      http://download.opensuse.org/repositories/network/openSUSELeap15.3/

      http://download.opensuse.org/repositories/network/15.4/

      I wonder what the reason was for this incompatible repo location change?

      BTW, also step 5 in that document can not be automated.

      • maverick74
        over 2 years ago by maverick74 | Reply

        It's broken?!

        My upgrade worked just fine the the only machine i have with Leap...

        (and yes... step 5 is a manual-thing, but... maybe that could already come as default, no?)

    • FabioMux
      over 1 year ago by FabioMux | Reply

      Unfortunately, things are not as easy as a simple zypper --releasever=15.3 ... because repository paths can change and third-party repositories might not be enabled at the time.

      That's why I spent some time building the script zypper-upgraderepo first and later the small interactive script zypper-upgradedistro to guide step by step through the needed operations to perform a smoother upgrade.

      They are already available in my repository

      Some references about the projects:

      • https://freeaptitude.altervista.org/projects/zypper-upgradedistro.html
      • https://freeaptitude.altervista.org/articles/upgrading-opensuse-leap-with-zypper-upgradedistro.html
      • https://github.com/fabiomux/zypper-upgradedistro
      • https://freeaptitude.altervista.org/projects/zypper-upgraderepo.html
      • https://freeaptitude.altervista.org/articles/upgrading-opensuse-with-zypper.html
      • https://github.com/fabiomux/zypper-upgraderepo

      • maverick74
        over 1 year ago by maverick74 | Reply

        I could not read the entire thing as i should (sorry... it's a lack of time!) and while the idea is about a GUI, your approach is also very interesting.

        But from what i could understand we need 2 scripts

        • the zypper-upgraderepo and
        • the zypper-upgradedistro

        is that right? (or did i miss something?)

        If we really need two: Why can't it be a one-script procedure?

        • FabioMux
          over 1 year ago by FabioMux | Reply

          There are two scripts only to keep the two concerns separated and better isolate and fix the issues later.

          So you can - upgrade/check/update the repositories URLs using only zypper-upgraderepo and do the rest by yourself; - upgrade your distro using zypper-upgradedistro, which makes use of the former script under the hood to achieve part of the job.

          That way, once it is perfected, we might evolve into a GUI (I was thinking of a Yast module) the zypper-upgradedistro script, which just reflects the steps listed on the official wiki, without rewriting, but integrating the job done by zypper-upgraderepo as an external library.

    Similar Projects

    This project is one of its kind!