A few years ago we were able to upgrade everything (OS and Apps) using a single command. I remember this was something we boasted about when talking to Windows and Mac fans. It was such an amazing feature. Something that users of proprietary systems hadn’t even heard about. We had this on desktops before things like Apple’s App Store and Play Store were a thing.
We can no longer do that thanks to Flatpaks and Snaps as well as AppImages.
Recently i upgraded my Fedora system. I few days later i found out i was runnig some older apps since they were Flatpaks (i had completely forgotten how I installed bitwarden for instance.)
Do you miss the old system too?
Is it possible to bring back that experience? A unified, reliable CLI solution to make sure EVERYTHING is up to date?
#nano /etc/systemd/system/flatpak-update.service
[Unit] Description=Update Flatpak After=network-online.target Wants=network-online.target [Service] Type=oneshot ExecStart=/usr/bin/flatpak update --noninteractive --assumeyes [Install] WantedBy=multi-user.target#nano /etc/systemd/system/flatpak-update.timer
[Unit] Description=Update Flatpak [Timer] OnBootSec=2m OnActiveSec=2m OnUnitInactiveSec=24h OnUnitActiveSec=24h AccuracySec=1h RandomizedDelaySec=10m [Install] WantedBy=timers.target#systemctl daemon-reload
#systemctl enable --now flatpak-update.timer
This should be added as hook to apt… as well.
I still run everything I can as .rpm through dnf on my Fedora and .deb through apt on my Debian servers.
I only install a flatpak as last resort.
From a dev viewpoint I can understand the gains of flatpak but from a user viewpoint I prefer a “real” install.It depends on the distro I am on, if I use Debian or a derivative I usually prefer the Flatpak but on Fedora I only go with the Flatpak if I run into issues or the rare outdated package because I don’t need them, I would certainly miss Flatpaks if they didn’t exist tho!
It’s funny, I do almost the exact opposite–whenever there is a flatpak version, I prefer it over a built-in apt package. The flatpak is almost always more up-to-date and often has the features and bug fixes I need.
Examples:
- Vorta (0.8.12 flatpak; 0.8.3 apt)
- Pinta (2.1.1 flatpak; 1.6 apt)
- Minder (1.15.6 flatpak; 1.13.1 apt)
- Xournal++ (1.2.1 flatpak; 1.1.1 apt)
.
I don’t think it’s fair to expect the distro maintainers to be up to date with every software out there–the universe of software has grown and grown, and we just can’t expect them to wrap/manage/test every new release and version bump.
Using EndeavourOS ( Arch ) and all four of those are the same versions in the regular repositories.
I agree that Flatpak is a solution to outdated packages. My preference is to use a distribution that does not have that problem to begin with.
Is it true flatpaks take up a lot more space due to bundling in dependencies etc?
The short answer is “yes, but only as much as it needs to”. Flatpak had to make a decision between “do we guarantee the app will work, even with system upgrades” or “do we minimize space” and they chose the former. The minimum necessary dependencies will be installed (and shared) amongst flatpaks.
Have you had the unfortunate experience of a utility or program losing its packaged status? It’s happened to me before–for example fslint. I don’t think this can happen with flatpak.
Space usage under flatpak is highly overstated. It only takes a noticeable amount of storage if you only use a couple of flatpaks, cause all the dependencies are used for a single package, once you start using flatpaks as the main mean of installing “applications”, the space required start to decrease because the dependencies are shared between multiple apps
I enjoy that extra stability and separation between system and apps, especially as I use a rolling distro as a gamer. Hearing talk about Flatpak I disliked it for the same reasons, but I decided to try it out after Steam Native bugged due to a system library update. I enjoy it now also because it feels good that installing apps don’t get a root password and scatter files everywhere they please in the system.
On servers it’s different ofcourse, Flatpak is basically for desktop apps. Snap is also designed for text mode stuff, servers and IoT devices but there’s the problem with it being controlled by one company.
deleted by creator
I use Fedora for work, but ArchLinux at home. If you really want to skip
flatpakthen you need the AUR.I mostly stick to things in the repos, if theres something I want that’s not yet packaged I package it myself because Gentoo packages are fancy bash scripts with libraries (eclasses) to handle the normal make && make install sort of things for most build systems
deleted by creator
I know that a lot of people share the same thoughts with you but I respectfully disagree. If you want your system to be updated only with your apt/yum/dnf program, then just don’t install anything useing snap/flatpak/etc. Sure, you will not have all the apps available in the repos, which was also the case in the past before these systems. Back then, your only option was to compile from source, which was more work-intensive than flatpaks/appimages/snaps. And updating was also much more complicated. Therefore, unless you wanted something really special, you’d stick to your repos. Flatpaks allow developers to distribute their software (and users to install it) in a less labour-intensive manner for the developer. Compiling and testing your app for Debian, Fedora, Arch, SuSE, MX-Linux, Linux Mint, Linux Mint DE, Gentoo, and all the other popular distros is an impossible task for small developers. Flatpaks was a godsend for them and for the users who don’t want to compile from source. Now, you can argue that we shouldn’t have all these systems (flatpak, snap, appimage, docker, etc…) but one would be OK. And again I will disagree. One of the most important aspects of FOSS is diversity. Embrace it even with its drawbacks. It would require a much longer post to explain this and others have done it already better than I would.
The official software manager on my Fedora system (Discover) presents me with Flatpaks. If I use Discover for updating ,the Flatpaks will update too. But when I use the official CLI tool to upgrade the system only RPM packages are updated. The other package managers on the system are not affected (Flatpaks, Snap, Cargo, PIP). I think there should be no discrepancy between CLI and GUI interfaces for system updates. The fact that I should “remember” how to update stuff shows that something is wrong or is not perfect.
You have a point here indeed. But it is much easier to create a CLI tool that combines the updates of all systems rather than destroying the incredible things that flatpak and pip offer. A five-line bach script would do. Although, a reliable distro would probably want to rely on something much more elegant and harder to break. For Fedora specifically, the python-based dnf tool should be straightforward to be extended to do that. Perhaps the Debian apt tool has a lot of functionality to carry on and may be harder to do. In the essence of unix philosophy and modular approach, it should be a separate tool. I’m looking forward to that too.
We can no longer do that thanks to Flatpaks and Snaps as well as AppImages.
That is a you-problem to be honest. If updating the system needs more than one command, then something is wrong with the distribution.
If you install applications using something else thatn the system’s package manager, you need to take care of them by yourself, too.
Also:
alias update=‘pacman -Syu && flatpak update && flatpak remove --unused --delete-data && snap refresh’
AppImages need to be updated individually, but AppImages suck anyways.
Flatpaks have crappy names and a crappy CLI. Snaps just suck, and AppImages need a package manager.
This is why I really like KDE Plasma’s discover. It’s got integrations with apt, snap, Flatpack, and rpm, and that’s only the ones I’ve tried so far.
I don’t really use discover itself to manage my packages, cause for some reason I prefer to do it with the cli tools, but it is a great update notifier.
Except it doesn’t always work. I’ve seen it stuck and loading updates forever a few times, while a simple flatpak update command did the job with zero issues.
Yeah that’s why I don’t use discover to do the actual updating. I just manually run my flatpak updates when discover tells me there are some.
Well, are you in pro of flatpaks or against flatpaks?
Why compare what OP described to flatpaks, instead of the “killer features” you so miss?
There has always been the option of installing software from source. The package manager won’t update anything installed from source.
You don’t have to use Flatpak, Snap or AppImage if you don’t want to. If you use the package manager to install everything, it will update everything.
Except doesn’t ubumtu now force a snap on you even if you try installing a package app?
deleted by creator
I’m confused by this. If I run apt install, am I getting stuff from flatpak?
You have to check your distros info, but from popular Linux podcasts they were claiming certain distros used the apt get but once the package manager saw what you want it would throw in a snap or flatpak of the same. Not all distros. I think Ubuntu was one.
Yes and no, you’re getting stuff form Snap, not flatpak
Even when I’m running apt directly? That seems insane.
Yep, that’s why some people are so upset about it. I guess there’s a config to disable it but I wouldn’t know, I use Arch btw
The solution is to use any of the other hundreds of readily available distributions.
Exactly. I dont have flatpak or snap integration installed so packages are packages. I think it was Ubuntu being delivered with snap as part of the OS. As well as CLI ads.
Yes. Some packages are just meta packages for their snap versions.
The package manager won’t update anything installed from source.
emerge lols
Portage: Am I a joke to you?
If I use ubuntu I’m somehow forced to use them.
Even on Fedora the average user is presented with many flatpak results when they use the GUI software manager. Not everyone is technically adept enough to check the origin of the app. So it’s kind of being forced on users.
so ditch this nonsense and use a better distro?
You can use bauh. it is a graphical app manager which can Install and update appimage, deb, flatpak, snap and web apps. https://github.com/vinifmor/bauh
If I use ubuntu I’m somehow forced to use them.
Yes, that’s why I stopped using it years ago (among other reasons).
Users are not out of options, they don’t need to check the origin of the apps themselves, it’s enough to ask other users what distros don’t do the things they don’t like and use those.
If you use the Fedora software manager it updates everything at once? It even updates BIOS firmware.
deleted by creator
You are just spreading FUD for the sake of it.
Snaps are updated automatically: https://askubuntu.com/questions/1262058/what-are-the-snap-equivalent-of-apt-get-update-and-apt-get-upgrade/1262059#1262059
Flatpak updates are usually integrated as hooks of the package manager (Archlinux handles this for you automatically, and I’m sure other distros do as well).
And on top of that, there’s also packagekit to handle all of this automatically.
I dont understand how that comment spreads fud. If you think theyre wrong just say it
alias upgrade=“sudo pacman -Syu && yay -Syu && sudo flatpak upgrade”
&& snap refresh
I think a lot of people just won’t endorse snap as long as it’s backend is proprietary
snaps are terribly, terribly slow, especially if you still have a mechanical drive.
What you suggest works for Arch distros only of course. Actually, yay -Syu will do the pacman stuff for you first anyway so you can skip that.
If you are using EndevourOS, check out eos-update. I just discovered it. It is basically the same thing but it will automatically handle keyring updates and db.lck issues if you have ever run into those. Basically, it is what yay should be.
Another EndevourOS gem is eos-shifttime. It will set your system to whatever pacman would have done on a specific date. You can use it to roll-back to a specific date. Or, if it has been forever since you upgraded, it lets you upgrade more incrementally than catching up all at once. Pretty cool. I guess you could also mimic the Manjaro experience by always upgrading to whatever was in the Arch repositories 3 weeks ago.
Of course those commands only work for arch-based distros, but it is completely possible to adapt them to fedora or debian-based distros
A few years ago we were able to upgrade everything (OS and Apps) using a single command. I remember this was something we boasted about when talking to Windows and Mac fans. It was such an amazing feature. Something that users of proprietary systems hadn’t even heard about. We had this on desktops before things like Apple’s App Store and Play Store were a thing.
If this actually were Linux’s killer feature, then Linux would have had a much higher market share by now.
Make no mistake, this is my favourite feature of Linux as well, and I have never used a snap/flatpack/appimage in my entire life. But it doesn’t have the kind of broader public appeal that you seem to be suggesting.
It’s not really lost ether tho, just add a simple bash alias and you are ready!
alias update='sudo pacman -Syu && flatpak update'or just use one of the trillion GUI app stores like pamac, discover, or gnome’s thing whatever they call it.We can no longer do that thanks to Flatpaks and Snaps as well as AppImages.
I heard about these things only on the internet. None of this exists on my system. So I’d answer ‘no’ to your question.
A unified, reliable CLI solution to make sure EVERYTHING is up to date?
It’s called
yay.I guess
yayis an easy solution, but it’s not very clean, at least from what I remember and just checked. It might be fine for single machines, but since it doesn’t build in a clean chroot, you can never be sure that the claimed dependencies are actually complete, and as such, a package built withyayon one machine doesn’t necessarily work on another, even for the same processor type (portability might not be possible anyways if you build with-march=native). It also doesn’t handle automatic rebuilds for necessary .so-bumps, but this is generally non-trivial to solve AFAIK.When I still used Arch exclusively, I had my own repository set up via
aurutilson a remote server, granted this doesn’t handle .so-bumps by itself either but at least you get somewhat clean packages every time, and you’ll start to notice how many AUR packages are actually broken, with the most common occurrence beinggitnot listed as amakedependsfor packages that retrieve their data via Git because everyone using the AUR has it installed anyways to access anything on there. Granted this is a non-issue in practice but it’s not the only one.I agree, but using yay, or rather the AUR, means being forced to use Arch. That’s not only annoying for the average Debian/shopless-distro-user that does not want to relearn their system, or sysadmin who does not want bleeding edge software to host their website (as it may be your favorite machine learning ‘anime’ generator that’s going down due to Nvidia drivers). It’s also deadly for the 69 year old grandma as she somehow manages to use flatpaks (or whatever) on Ubuntu, but forgets to update them. Meanwhile she, very consciously, updates everything else through the Software Center every day (or lets it auto update). She wouldn’t survive that jump to Arch (and certainly wouldn’t survive the compile times of some AUR packages). Everyone suddenly using Arch would crash the whole ecosystem and community. Sysadmins would need to switch to Arch quickly now, as it’s development stales because no one uses it.
The only solution would be, to create - yet again - a universal alternative to the AUR. Maybe someone, backed by eg. the Linux foundation itself, could create a good way of compiling AUR packages on every system. Now we would still have to somehow drop Flatpacks and Snaps (especially the latter), which some Distros will refuse to do. Canonical isn’t going to yeet snaps out of the Store because it’s shit and something better exists (because that would apply to the whole distro /s)
The only solution would be, to create - yet again - a universal alternative to the AUR.
