The idea is there should be an option in pamac-gtk to allow for flatpaks to be upgraded offline on shutdown, when “update system at shutdown” is also enabled. Currently, the system only updates packages from the official repos.
This idea could also be extended to AUR.
EDIT: Admittedly AUR would likely be dangerous to enable automatic updates from since they are not isolated from system packages, and could have unforeseen effects on the user. However, flatpaks are isolated from the system, and should be completely safe to update completely silently, as its not possible for a flatpak upgrade to break the system. I only mentioned the AUR as it is technically an option and logical extension of the logic for allowing offline updates of flatpaks.
I would shout from the treetops… absolutely not. Already the ‘update system at shutdown’ is a very Windowzy and dangerous option disliked by many afficionados.
Especially unpopular given that after shutting down, your system might never recover.
It must also be limited only to Official Repositories which are curated and tested by the Team.
There comes a time where the best answer is:
KISS
Convenience is the priority for Windows, at the cost of everything else. Experienced Manjaro users need to see what’s being updated - especially from AUR - and intervene as necessary, merging pacnew configs, which is removed bu automatic shutdown processes.
It’s also extremely complicated to implement, AUR packages may, or may not be pre-built (so maybe a half hour just for a single browser to build… leading to extremely unpredictable shutdown times).
Flatpaks manage their own runtime and app directories and tooling…
Also, Flatpaks are supposed to be app-level packages isolated from the core system.
So there’s a conceptual mismatch.
The best practice is to have your own ‘update everything’ command ready… choose your own poison:
#!/bin/bash
pamac update --no-confirm # Official system
pamac update --aur --no-confirm # AUR packages
flatpak update -y # Updates Flatpaks
I once built a firefox with the Plasma global menu patch from sources by way of the AUR — but with only makepkg and the PKGBUILD script, without using an AUR helper — and it took over 5 hours, with all six cores maxed out at 100% load and all of my RAM filled up (and about 80% of my swap partition).
The system was completely unusable during the build — even the clock in my top panel wasn’t updating anymore. I had to manually switch off the screen and go to bed. By the next day, I saw that the build had finished, and how long it had taken — I had timestamps in my bash prompt at the time.
That was almost six years ago now. And if you’ve read @Yochanan’s recent report of his failure to build firefox 142 on a server with 32 GiB of RAM and a 16 GiB swap partition, then you’ll also understand that building any modern browser from source code is not for the faint of heart.
Reminiscent of the Electron (25?) debacle after it was demoted to the AUR. Some found that the ~20 GB sources and the resource overhead was a little more than they had hoped for.
One of the reasons to look for a binary package instead (electron25-bin in that instance). I shudder to think of the a-typical “I don’t need swap” mindset struggling to build it otherwise.
Well it is an option for Flatpak, you need flatpak-offline-update.service. However, Manjaro isn’t set up for that - I’m not sure why but I do feel uncomfortable about automated updates on a rolling system.
I can understand. Flatpaks are isolated from the system though, so they should have no effect on the underlying system. Worst case, a particular flatpak application might be broken. So I think there should be a switch for it on the appropriate pamac-gtk settings page, which I guess would just enable/disable flatpak-offline-update.service.
It’s part of a systemd-based offline update mechanism that’s more common in enterprise or kiosk-style setups (e.g. Fedora Silverblue or Endless OS), where atomic updates and rollback safety are prioritized.
Manjaro, being Arch-based and user-centric, leans toward manual or interactive updates, especially for Flatpak.
I’d be shy to try - I prefer to avoid potential boot delays or update failures during startup.
Personally I think this whole update on shut down is a level of inconvenience. First of all you have to actually shut down, even when it is unnecessary, so that the updates will happen.
This may actually be a way to avoid the restart, restart and restart again dance on Windows, but it adds nothing useful to a Linux OS.
For “normies”, who tend to shutdown the system relatively often, I think it would be an overall good, as it would keep the packages updated and secure without manual intervention.
Or any. I’ve tried update on shut down, and from where I sit, it’s a regular POS, even on the computer I do shut down between uses.
It’s the waiting for it to shut down, so I can turn off the power to my music room, that I find really annoying, while a normal Linux update can take place while I’m doing other things including tuning up, or even doing other stuff on the computer that doesn’t include using anything required for actually recording.
This is just gatekeeping. Using any OS should be as painless as possible. I’m a firm believer that for example, that needing to use the terminal instantly loses the normie crowd. Keeping the system up to date for the user is is just a basic quality-of-life feature, that makes using the device a pleasure, and not have to worry about drivers, updates etc.
Its a point to illustrate that its an expected feature for users. Further, with Manjaro being pre-installed on many devices, its no longer an “enthusiasts-only” distro. People who are less experienced will use it. It will happen. Developers unfortunately don’t get to choose how the users use the product. That’s just reality.
Mod note:- Please avoid consecutive posts, especially when responding to the same person. Instead, please edit the existing post with your additional content. Posts have been merged.
I do have an understanding of what a UNIX system is. It is no different than any other system. It is a tool for people to use in their life. That doesn’t change no matter the OS. And as a tool, it should work for the user, the user shouldn’t work for the tool.
I have worked on kernel modules at work professionally.
This gatekeeping is what prevents Linux from becoming more popular on desktop.
Believing that people need to have some certain knowledge to be worthy of using an OS is not a good view to have. Using any OS should be as seamless as possible, and the system should get out of the users way as much as possible, and automatically updating is one feature to that end. As a community, we should seek to be as welcoming as possible to those of all knowledge levels, especially as an OS that is being pre-installed on many off the shelf machines.
UNIX is not user-unfriendly. It’s just picky about whom its friends are. And it was not designed to be used as a kitchen sink household device. It’s a real operating system.
You cannot apply the same ride-in-the back attitude of a taxi cab customer to what it takes to pilot an F-22 Raptor.
This is not gate-keeping. It’s a completely different paradigm, and it requires abandoning the paradigm of the system you’ve been indoctrinated with and conditioned by.
If the only tool you know is a hammer, everything else looks like a nail. Well, UNIX is not a hammer but a screwdriver. So use it for applying torque to screws instead of trying to hammer the screws in place.
Not a certain knowledge, but a willingness to change their attitude. And it’s not about being worthy, but about being successful.
