Draft: main: add gui for release upgrades (gnome-software)

added 1 commit

3372e16d - fix ci

Compare with previous version

By Andras Sebok on 2024-05-08T11:22:52

added 1 commit

64e57101 - fix ci

Compare with previous version

By Andras Sebok on 2024-05-08T11:24:54

added 1 commit

adb67f44 - fix ci

Compare with previous version

By Andras Sebok on 2024-05-08T11:29:18

added 1 commit

37078680 - fix build

Compare with previous version

By Andras Sebok on 2024-05-08T11:40:27

Wow, thank you so much! Is this something you decided to do on your own or did you coordinate this with any other team member/contributor somehow?

By Newbyte on 2024-05-08T14:32:19

Oh my, this is amazing!! Thanks a lot for writing all of this. Having a look at the gs-plugin-pmos code, it looks pretty sane from the GS point of view. However, I wonder if you are aware of https://gitlab.alpinelinux.org/Cogitri/apk-polkit-rs ? I believe a big chunk of the dbus functionality could and should be built in there. Mostly:

Updating the repositories to the new channel
Downloading to the cache, and then installing, instead of doing it all together

Feel free to reach out in the devel channel if you want to coordinate

By Pablo Correa Gomez on 2024-05-08T14:30:45

apk-polkit-rs has add_repository but it would be added immediately instead of waiting for reboot, and at that point it is easier to run cp /etc/pmos_upgrader/repositories_new /etc/apk/repositories in the upgrade script. I did not find any way to make it run apk fetch and it needs lots of options anyway so i think it is easier to just run it with subprocess.Popen.

By Andras Sebok on 2024-05-08T14:30:45

it would be added immediately instead of waiting for reboot

I would say that if that is a requirement, that is something that could be implemented there.

I did not find any way to make it run apk fetch and it needs lots of options anyway so i think it is easier to just run it with subprocess.Popen.

apk-polkit-rs uses apk-tools library. So the point is not throw commands, but to use the internals. For example, for syncing a repository to the cache it would be something like apk_cache_download. This after selecting the necessary packages with apk_solver_solve. This also possibly fixes the problem with "too many options"? As those are usually just some flags sent to the solver. Would you be up to try something like that?

By Pablo Correa Gomez on 2024-05-08T16:53:07

Yes, we can try implementing apk fetch and apk index this way but i do not really know rust so we would need to find somebody to do it (or wait until i learn it).

By Andras Sebok on 2024-05-08T18:08:36

I think I can help you with it, and we can totally wait for you to get up to speed with the language. The fact that you did a big bunch of the work (e.g: thinking about the interfaces, doing the plugin work, the service file, an alternate dbus service) is greatly beneficial. But from my point of view, there is no urgency to get this done

By Pablo Correa Gomez on 2024-05-08T18:21:10

I took the freedom to ping you in two issue upstream, and I'll also ping Cogitri about it, let's see if we can help get this integrated upstream and we can have everything in the same place (and also for alpine users :D)

By Pablo Correa Gomez on 2024-05-08T18:37:12

Very nice work!

maybe it would be a good idea to do a sinulation with apks -s option, to catch any errors before the actual update is started..

By Robert Eckelmann on 2024-05-08T14:29:13

added 1 commit

64ac8a9e - run apk simulate

Compare with previous version

By Andras Sebok on 2024-05-08T14:28:55

resolved all threads

By Andras Sebok on 2024-05-08T14:29:13

this is the new upgrading process based on the reviews:

gnome software checks if an upgrade is available (i am not sure how this would work on alpine without a channels.cfg file)
if an upgrade is available, gnome software sends a notification and show a banner in the updates page
- in the future, we could design a postmarketos/alpine themed banner
(the user clicks on the download button)
gnome software calls the AddToRunlevel dbus method (in a new dbus api for talking to the init system)
- adds apk-polkit-rs to the upgrade runlevel
gnome software calls CachePackages dbus method (in apk-polkit-rs)
- downloads packages required for the upgrade
- makes a file with the new repositories
gnome software changes the DefaultRunlevel property of the init system dbus api
gnome software asks the user to reboot
after reboot, openrc will boot into the upgrade runlevel
(apk-polkit-rs detects that we are in the upgrade runlevel)
- shows splash screen with "Upgrading {DISTRO NAME}" message (we need to move pbsplash to alpine/aports for this to work)
- upgrades the packages downloaded before (with apk fix)
- makes a backup of /etc/apk/repositories
- reads the new repos from the file created before and adds them to /etc/apk/repositories
- resets the runlevel to default
- reboots
the upgrade is finished

i will start implementing this but it will take a while.

By Andras Sebok on 2024-05-23T16:48:48

Hi, thanks a lot for your thoughts!

gnome software checks if an upgrade is available (i am not sure how this would work on alpine without a channels.cfg file)

This should be done with AppStream metadata that we should ship to the previous stable release. There's a whole category about it: https://www.freedesktop.org/software/appstream/docs/sect-Metadata-OS.html See the eos plugin in GNOME Software for a similar approach It should be totally fine to limit the scope of this plugin to upgrade from stable release to stable release.

in the future, we could design a postmarketos/alpine themed banner

I am pretty sure GNOME Software has support for it (document even under docs/vendor-something?) Again eos plugin (it's a terrible name, but works)

gnome software calls the AddToRunlevel dbus method (in a new dbus api for talking to the init system)

I was wondering if we should not simply always do this? This might be helpful for other things than not only stable release upgrades. Like ideally one won't flash the kernel on a running system, but maybe during shutdown/startup?

I think most of the other things make complete sense. Probably really starting by adding support for offline updates to apk-polkit-rs and gnome-software-plugin-apk will already be a huge improvement. Huge thanks for this work!

By Pablo Correa Gomez on 2024-05-23T16:48:48

I was wondering if we should not simply always do this?

I dont think there is a way to safely avoid doing this on release upgrades.

This might be helpful for other things than not only stable release upgrades. Like ideally one won't flash the kernel on a running system, but maybe during shutdown/startup?

This can be used for kernel updates but i do not know of any reliable way to check if we are about to install a kernel update in the gs-plugin.

Probably really starting by adding support for offline updates to apk-polkit-rs and gnome-software-plugin-apk will already be a huge improvement.

I am working on the CachePackages method in apk-polkit-rs that can be used for this (right now its just calling apk_solver_solve and apk_cache_download). It still has some bugs, i will submit a mr when they are fixed.

By Andras Sebok on 2024-05-24T09:16:30

I dont think there is a way to safely avoid doing this on release upgrades.

I think probably my wording was not clear. I mean that we could simply just always do it. Regardless of whether it's a release update. That means it will be easier to test that path, and has some extra benefits as outlined below.

This can be used for kernel updates but i do not know of any reliable way to check if we are about to install a kernel update in the gs-plugin.

Well, we could use it for everything that is not an "app", e.g: system updates (don't remember the exact wording in GNOME Software for it, but that's easy to detect). In the end, every running daemon or loaded library will continue using the old binaries until a re-start?

By Pablo Correa Gomez on 2024-05-24T09:38:12

marked this merge request as draft

By Andras Sebok on 2024-05-18T08:34:17

Related: apk-polkit-rs/#15 and apk-polkit-rs/#18

By Andras Sebok on 2024-05-18T08:52:13

The CachePackages dbus method is implemented in apk-polkit-rs/!50

By Andras Sebok on 2024-06-14T17:12:22

added status::mr-stale label

Sorry to bother you @andrisas,

but we've detected that this merge request hasn't seen any recent activity. If you need help or want to discuss your approach with developers you can ping @postmarketOS. You can also ask on matrix in #devel:postmarketos.org or #postmarketos-devel on OFTC. If no further activity occurs in this MR, postmarketOS developers may close it in the future.

Thanks for your contribution.

By * postmarketOS Bot on 2024-09-27T19:09:35

closed

mentioned in issue #1432

Draft: main: add gui for release upgrades (gnome-software)

pmos_upgrader.cfg

Debugging

Activity

Draft: main: add gui for release upgrades (gnome-software)

pmos_upgrader.cfg

Debugging

Merge request reports

Activity