You are not logged in.
AUR's Firefox forces you to restart once an update is downloaded, however Flatpak's Firefox doesn't do that.
I'd like to know why the AUR version forces the user to restart the program, because letting the user close the app on their own would be much more intuitive.
Offline
What "AUR's Firefox" are you talking about?
Offline
What "AUR's Firefox" are you talking about?
I mean the one you get by entering "sudo pacman -S firefox" on the terminal.
Offline
well that has nothing to do with the AUR at all, that's firefox from the Extra repo. And there's nothing there that automatically restarts it at all.
Offline
well that has nothing to do with the AUR at all, that's firefox from the Extra repo. And there's nothing there that automatically restarts it at all.
What actually happens is that it stops loading pages, and tells the user to restart Firefox in order to install the new update.
Offline
So apparently the way that Flatpak handles updates just so happens to be effective against Firefox's aggressive approach to updates.
"Flatpak apps run in a container, and the update process updates the container image. So the app is entirely unaffected until you close it and run it again."
Offline
For clarity :
Are you running pacman -Syu while in a GUI environment and having applications open ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
For clarity :
Are you running pacman -Syu while in a GUI environment and having applications open ?
Yes.
Technically speaking, pacman is doing it the correct way, and flatpak is doing the wrong way. However the wrong way is better at dealing with this unnecessary design choice by Mozilla.
Offline
I assume the "unnecessary design choice" is basically the multi-process approach and if you replace the on-disk binaries, FF will detect the incompatible version change and require a restart.
The same happens when you let FF run an internal update (which iirc is disabled on most distros but the common way eg on windows)
There's no way around that unless FF copies itself and all relevant libraries completely (in doubt into RAM), effectively creating a transient homebrew flatschpak.
Flatpaks simply never get "updated" at all.
You install another flatpak, the previous one will remain available until the last filehandle is closed or you're running out of inodes.
Offline