Fedora Atomic: How do you prefer updates? Through the Software center, CLI, background?

Ask Fedora
, , , , ,
1

The Fedora Atomic Desktops do something new by clearly separating the System from the Apps.

I think this is a great approach, as the user pretty much doesnt have to interact with the system in any way, by using Flatpaks.

Current implementations into GNOME Software and KDE Discover allow users to see updates of the system in these Stores though. Discover also now seems to allow installing apps as RPMs (layering) from the store. Probably uninstalling (not override remove) too.

What do you prefer, how do you do your Updates, how do you use these Stores?

  1. Updates and Installs (Flatpak and RPM layering) through the GUI Software stores
  2. Updates + RPM layering through CLI manually, Flatpaks through GUI
  3. Updates through an automated background service. Manual installs through GUI
  4. Updates through an automated background service, only Flatpak installs through GUI. RPM layering through CLI.
  5. CLI for everything

Second question:

Would you like to have notifications about updates seperated from the main software center?

The purpose of this survey is to get an idea of how people like to do this. Poorly Discourse has no real survey tool.

1 Like
2

I personally to 4. I see no value in having interactive and kinda crashy updates through packagekit, if I click “yes” 100% of the time.

I have disabled any Discover background notifications and have a background systemd service updating rpm-ostree and flatpak.

Only waydroid (sudo waydroid update) and fwupd are not yet automated.

fwupd is a pretty annoying thing, as it requires some sort of battery detection, a GUI kdialog (yes/no) reboot dialog and all. But then, it could be done.

I want to use Discover for Flatpaks only. No loading when launching it, simply to discover new apps. I have never installed an RPM there, as the best way to do these changes is via a combined command like

rpm-ostree update --install A B --remove B C
3

I prefer 5, mostly because I like the control I have and because I feel like gnome-software is slow on the first update and occasionally glitches.

Granted some of this may be due to my prior “slow” internet situation, and because I’m an old terminal fuddy duddy…

1 Like
4

In your options list, does ‘installs’ mean layered RPMs or flatpaks?

I’m pretty happy with GNOME Software with automatic updates enabled (for both rpm-ostree and flatpak). Performance is mostly fine now, but memory usage is still a bit high. I typically use it to install flatpak apps as well.

If I may be pedantic, PackageKit isn’t installed on Atomic systems. Software and Discover talk to rpm-ostree directly.

1 Like
5

1 all the way. CLI only on emergencies or when I absolutely need to layer something

7

No this is important! Thanks for the heads up, removed it. If Discover and Software dont need Packagekit for rpm-ostree I think thats something good.

Figured out for install I would need some more options… will get messy. Edited the questions to be more clear, still not really covering every option for the sake of usability.

Added the new question I wanted to go towards.

8

I personally prefer 5, but I think this should not be the only option.

Besides updating rpm/rpm-ostree and flatpak, don’t forget Gnome extensions and firmware (fwupdmgr).

1 Like
9

I personally do 2. I like to see what’s different about system updates, and that isn’t visible through Discover.
I want to somehow disable Discover from using rpm-ostree (only on my system), because Discover has too high a frequency of checking for updates to the system. Basically every hour or so, feels like. It’s annoying and a waste of cpu.

Ideally, if these two drawbacks were addressed, I’d be comfortable going GUI-only for the most part.

1 Like
10

#3 already is happening. #4 is an arbitrary separation at this point, Gnome Software and Discovery already combine sources from flatpak and package repos (ie #1). The CLI methods for both flatpak and rpm-ostree have much needed functions when problems arise.

11

I do sort of a sporadic mix of all the above: I appreciate automated updates, and alternate between GUI and command-line tools depending on whether I want to browse for possible solutions (GUI) vs install known and specifically desired software (CLI).

I do tend to run manual extra system updates in the terminal periodically just because it feels safer, especially when I know there’s a new kernel or GPU driver. I always run a script with batched tasks like force-rebuilding the initramfs because Nvidia has burned me enough times in the past.

12

I like to use cli because I don’t feel like other methods are verbose about what’s actually happening.

I don’t want any notifications for updates, I don’t care if an app has updates, I usually update all my apps at once when I feel the need.

1 Like
13

I tend to use cli only.
I much prefer the feedback about what is happening and the ability to update at my own schedule.

The default with the gui does automatic offline updates and does not inform the user about what is updated as well as at times forcing a reboot. This is not appropriate for my workflow.

1 Like
14

I agree that the CLI is the only fast way and with full information .

Doing updates when you feel like it is pretty ironic, I dont think you feel security updates XD

I am working on my systemd script for autoupdates, but I think its broken and I update daily before shutdown with a special alias for flatpak, distrobox and rpm-ostree.

I mainly need this for all the “unsupervised machines” by family members, where they simply dont update, ever. They will not press on some random update button. It has to be automatic and stop when it would annoy or cause high cell data loss.

If you have writable firmware (which dasharo coreboot is not, for security reasons), fwupdmgr should also always be used.

in my approach I try to make the necessary parameters configurable and transparent:

  • system load
  • battery state
  • optional: AC connected
  • metered or unmetered network

and try to create a persistent notify-send notification that doesnt go away (-t 0), with the rpm-ostree changes.

also, I try to make a log file with all the changes.

15

i do everything that i can from GUI, only things that i can’t do from GUI that i use CLI(like layering or rpm-ostree status), but would be interesting to do that from GUI

1 Like
16

rpm-ostree does not work well with the new app store model but better with the old one (fetch packages, select packages, install them at once)

i would also be interested in an “atomic desktop manager”, which is very needed. but dont have the time or coding experience, yet

17

that’s why the push to flatpak and containerized applications, it can be installed without changing the host system, there’s usr-overlay tho, that would work, when clicking install in the store it automatically unlocks the file-system and install it, or maybe soft-reboots when ostree dnf add support for it, but that would log-out your user, so not too straightforward

18

well, if I should get frustrated here.

my change to add a flatpak group was rejected. so the main way to install apps, preconfigured, and including systemd sysextensions, still requires the wheel group.

this makes Fedora Atomic inherently more insecure than Android. simply because the Atomic images are incomplete or broken on NVIDIA without layering. while systemd sysextensions could possibly remove the need for layering.

so you need system flatpaks, using both a system and a user repo is a bad concept and duplicates tons of packages.

but I guess by then, I can make another change proposal

19

to be fair, android apps don’t have full access to your system, like flatpak with systemd sysextensions and with home access, and the nvidia issue is more about fedora open-source philosophy than a technical issue, maybe with nvidia opensource efforts this change in the future