As is (for the last few years), if you set the PK_OFFLINE_UPDATE environment variable, it should already work. We decided not to make it the default because most people are still installing most of the applications from the distro and this makes it cumbersome.

My impression (as Discover maintainer) is that if people started to adopt flatpak/snap/younameit as a way to install their apps, the usability of this feature would drastically improve.

That said, I'd be happy to make it easier for you to use it. Also please test it, it's not very well tested yet, I'll be happy to fix whatever we need.

At the moment, I'm mainly interested in doing offline updates for OS upgrades. That is, doing Fedora 32 to Fedora 33 upgrades through an offline update system upgrade. Regular updates and whatnot probably aren't ready to change over.

With GNOME Software, there's a way to do OS release upgrades by triggering the offline updates mechanism, and I'd like to see if we can do that for Plasma Discover too.

I see, this is ad-hoc for upgrades. I still think it would make sense to have most of the system upgrades offline.

Usually such specific tasks are done more comfortably from a distro-specific app with its status notifier. What kind of integration would you like to see in discover beyond the "press here to upgrade to Fedora N"?

Well, patches welcome I guess. If you want to know how to do that, I'll be happy to answer.

It seems like @rdieter has started working on having offline updates enabled for even regular updates for Fedora 34, so I guess we should start planning for offline system upgrades for F34 too...

@bcotton put this in the Fedora 34 Final Blocker Review email last week:

2. LiveCD - KDE — https://bugzilla.redhat.com/show_bug.cgi?id=1939751 — NEW
KDE live image shows update notifications

Discover shows that updates are available, which live images are not
supposed to do. I looks like we need to remove plasma-discover in the
kickstart for KDE Live the way we've previously done for
plasma-pk-updates.

@rdieter what does this mean?

f34 https://pagure.io/fedora-kickstarts/pull-request/789
rawhide https://pagure.io/fedora-kickstarts/pull-request/788

Posted updated PR's in bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1939751

At this point, we've got basic offline updates in place for Fedora Linux 34. The remaining thing to do here is to get Discover extended to support the same offline full system upgrade workflow that exists in GNOME Software. We've discussed in today's meeting and @siosm will work on implementing this, since he's already working in Discover for Kinoite work.

What workflow is this?

@apol It's the workflow for notifying the user and triggering a system upgrade from one Fedora release to the next. This is something that exists in GNOME Software and people have asked us to have this in the KDE spin through Discover somehow.

:tada: Found the link to the API/JSON in GNOME Software (https://gitlab.gnome.org/GNOME/gnome-software/-/blob/main/plugins/fedora-pkgdb-collections/gs-plugin-fedora-pkgdb-collections.c#L16): https://admin.fedoraproject.org/pkgdb/api/collections/

Will look at adding support in Discover next.

Upstream bug report: https://bugs.kde.org/show_bug.cgi?id=446924

Some notes from @mcrha on how this works in GNOME Software:

Just call functions from the pk-offline.h; if I'm not mistaken, then:

pk_offline_get_prepared_ids() to see whether there are prepared updates:
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/9643b1c6/plugins/packagekit/gs-plugin-systemd-updates.c#L97

pk_offline_trigger_with_flags() to prepare the update (aka to download it):
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/9643b1c6/plugins/packagekit/gs-plugin-systemd-updates.c#L267

pk_offline_trigger_upgrade_with_flags() to execute the upgrade (that's under
the 'Restart & Update'):
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/9643b1c6/plugins/packagekit/gs-plugin-systemd-updates.c#L286

Note these functions are wrapped in the gnome-software, because there
had been done a change on the PackageKit side, which the API may not
have covered, thus there are done direct D-Bus calls when the
PackageKit API is not new enough.

@siosm Is there any improvements on this?

Package review in progress to help with that: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2068492

Ping here. I would appreciate if someone could review my new package above. Thanks!

https://bodhi.fedoraproject.org/updates/FEDORA-2022-4bb9a0f4de > New package update

It's now in F36 so I'll make Discover recommend it.

https://src.fedoraproject.org/rpms/plasma-discover/pull-request/11

Can you explain to me how that will work? It will be useful to understand how our users experience it in Fedora.

@siosm I have a question as well:
does this means that on Fedora 36 Discover will already be able to notify me of Fedora 37 and to perform the upgrade entirely thru the discovery GUI?

This adds the metadata needed for Discover to know if the release is EOL or if a newer one is available.

I have not looked at the code in Discover yet that does the upgrade to see if this works.

I'm considering migrating a few machines into Fedora KDE but i'm depending on this feature, (because one of the main reasons to do so is for the machine users to get some independence and be able to perform such upgrades with no expertise requirement)
I do not want to move into this if i have to manually perform the upgrade later via CLI.

I would like to ask one question @siosm (sorry for so many questions, you can reply when you get time for it):

Is this something that we can hope for Fedora 36? Or will it be only for 37 or some later version?

If you plan on getting this into 36, i could start migrating right away... tks

The Fedora Project is a community project. Changes happen when contributors make them happen. This issue is explicitly labelled Future Release. If you're interested in contributing support for that in Discover, feel free to start working on it and we can collaborate to make it happen.

Some notes from @mcrha on how this works in GNOME Software:

Just call functions from the pk-offline.h; if I'm not mistaken, then:

pk_offline_get_prepared_ids() to see whether there are prepared updates:
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/9643b1c6/plugins/packagekit/gs-plugin-systemd-updates.c#L97

pk_offline_trigger_with_flags() to prepare the update (aka to download it):
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/9643b1c6/plugins/packagekit/gs-plugin-systemd-updates.c#L267

pk_offline_trigger_upgrade_with_flags() to execute the upgrade (that's under
the 'Restart & Update'):
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/9643b1c6/plugins/packagekit/gs-plugin-systemd-updates.c#L286

Note these functions are wrapped in the gnome-software, because there
had been done a change on the PackageKit side, which the API may not
have covered, thus there are done direct D-Bus calls when the
PackageKit API is not new enough.

@mcrha this is missing perhaps the most important bit: how do you get the list of package ids?

Some notes from @mcrha on how this works in GNOME Software:

Just call functions from the pk-offline.h; if I'm not mistaken, then:

pk_offline_get_prepared_ids() to see whether there are prepared updates:
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/9643b1c6/plugins/packagekit/gs-plugin-systemd-updates.c#L97

pk_offline_trigger_with_flags() to prepare the update (aka to download it):
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/9643b1c6/plugins/packagekit/gs-plugin-systemd-updates.c#L267

pk_offline_trigger_upgrade_with_flags() to execute the upgrade (that's under
the 'Restart & Update'):
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/9643b1c6/plugins/packagekit/gs-plugin-systemd-updates.c#L286

Note these functions are wrapped in the gnome-software, because there
had been done a change on the PackageKit side, which the API may not
have covered, thus there are done direct D-Bus calls when the
PackageKit API is not new enough.

@mcrha this is missing perhaps the most important bit: how do you discover the list of package ids?

this is missing perhaps the most important bit: how do you discover the list of package ids?

See the /usr/include/PackageKit/packagekit-glib2/pk-offline.h there's pk_offline_get_prepared_ids(). The offline updates API is very simple.

That just reads back the prepared-update file, but how do you write it in the first place.

You do not, it's responsibility of the PackageKit itself.

Yes, by which call?

Yes, by which call?

To download updates:

pk_client_get_updates_async (..., pk_bitfield_value (PK_FILTER_ENUM_NONE),... )

followed by pk_task_update_packages_async() where is passed list of packages returned from the previous function and the update_task itself has set pk_task_set_only_download (task_update, TRUE);

Once it's done you can call pk_offline_trigger_with_flags() with PK_OFFLINE_ACTION_REBOOT. The gnome-software uses the D-Bus interface for it:
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/824f46052d7aee8ed5987125e92cb92edf5c1f40/plugins/packagekit/gs-plugin-packagekit.c#L4019

No, get_updates doesn't fetch distro upgrades. I believe you are using upgrade_system(distro_id,...), i have a half working implementation using it

Can, be. I looked into the sources only briefly. I'm sorry for the confusion.

This has now landed for the next version of Plasma Discover: https://invent.kde.org/plasma/discover/-/commit/294354b548b6382810da13a7f7319db3f60d2cb3

Thank you @aleasto for doing the work!

This is now marked as pending for us, to be qualified and integrated with Plasma 6.0.

This is now marked as pending for us, to be qualified and integrated with Plasma 6.0.

Excellent news! Is this specific to Fedora KDE, or is Fedora Kinoite also supporting the new feature in Plasma Discover to notify the user of the next 6 month major release being available to rebase to?

Kinoite already supported this.

Fantastic news!!!
Thank you so much!!!

Is there any chance of getting this backported to Plasma 5.27 (or to Fedora 39)?

Maybe :)

Awesome!!!

Can this be closed?

Well, it depends on whether we want to backport this or just wait for it to arrive.

(And to be clear, that's mostly based on figuring out timelines for Plasma 6.0 in relation to Fedora releases...)

Related to this work, we're also enabling automatic updates by default: https://src.fedoraproject.org/rpms/plasma-discover/pull-request/14

Kinoite already supported this.

It does not as far as I can tell. I'm running the latest released version of Discover, 5.27.4, and on Kinoite 37.20230428.0 and after 1.5 weeks since Fedora 38's release have had no notifications of any sort by anything on my system that Fedora 38 has been released nor an easy one click GUI upgrade like GNOME Software presented in Discover. Discover supports daily commit upgrades (37.20230426.0 -> 37.20230428.0) as part of the 'Operating System' category, but it doesn't seem to support Fedora Kinoite 37 -> 38 upgrades in any capacity until Discover 6.0 is distributed.

https://bodhi.fedoraproject.org/updates/FEDORA-2023-8af3f0432a needs to land in stable for Discover to know F38 is available.

https://bodhi.fedoraproject.org/updates/FEDORA-2023-8af3f0432a needs to land in stable for Discover to know F38 is available.

Thanks, can confirm it's now in stable so the notice header does show in Discover 5.27.4! Since this issue concerns improving Discover around this upgrade process I have two minor suggestions to push upstream to KDE to improve the user experience if they aren't already in dev Discover 6.0 or dev 5.27.5 :

1. When selecting the install button from the notice header, bring up the 'Tasks' pop-up to show that work is being done so the user doesn't try to reboot or something else. Currently when you select the Install button from the header it kicks off Tasks in the left side menu where it isn't as visible that an install is now happening
2. When finished downloading and installing, kick the Discover main pane into the Updates view that shows a reboot now needs to happen OR trigger a pop-up a reboot needs to happen to finish the major upgrade

What about Fedora KDE "normal" (not Kinoite)?
Is that still planed "just" for Plasma 6?

Or will the 38 normal spin get it backported? Any decisions of that already?

(I've seen the milestone=plasma6, but sometimes that's not up to date. Sorry for the noise, anyway)

We haven't decided yet if we want to backport it.

Considering that KDE Plasma 6.0 should have a february release, which means it falls for the most part in Fedora 40 cycle. Would this change be included in the still 5.27-based Fedora 39 or even get backported covering Fedora 38 too? Or is this already too late and off-limit for the mentioned releases?

Considering that KDE Plasma 6.0 should have a february release, which means it falls for the most part in Fedora 40 cycle. Would this change be included in the still 5.27-based Fedora 39 or even get backported covering Fedora 38 too? Or is this already too late and off-limit for the mentioned releases?

This was already backported to F37 and F38. You'll be able to upgrade to F39 with Discover. Please participate to F39 upgrade test day! https://testdays.fedoraproject.org/events/158 at KDE/plasma-discover-current

This is now implemented.