hmm it’s cool that you can use snapper on Arch. This would put it on par with openSUSE in terms of stability, no? Assuming that the snapshots appear on GRUB and that the user does not need to chroot to rollback if the system is borked.
Doesnt GRUB not work well with LUKS? Also apparently snapper rollback doesnt work well on Arch
Works well for me.
Why?
I have a wonky setup for my laptop: 1 SSD partitioned into 2 and both are protected with different LUKS password: one for / (root) and another for /home and I’ve yet to break it 
which is amazing. Somehow I can only do this particular setup with Fedora’s installer but I havent really given it a good try.
openSUSE has an additional automated QA testing process. Despite this, there are still some problems.
The rollback method explained on Arch wiki is different from the one used on openSUSE distributions. Instead of struggling with the potential issues of GRUB, an alternative to rEFInd (+refind-btrfs) can be tried. There are also packages snapper-rollback and yabsnap that claim to automate the rollback method explained on Arch wiki.
openSUSE has made many modifications to keep the default rollback method stable. It is understandable that the vanilla snapper rollback doesn’t work on other distributions. Arch requires a few tweaks to make the default method work.
How do you manage with apps that are only available in .deb and no ports by community fedora or copr repos ?
Yes, if you use the actual installer. But when you boot into live mode and click install. You have the calamares installer which is way better.
I’m not using Fedora, but it’s very easy to do on openSUSE Aeon.
Open the terminal
distrobox- create --name debian-12 --image debian:latest
distrobox- enter --name debian-12
Install Signal on the distrobox (they only provide .debs)
distrobox-export signal
Now Signal will appear in your app launcher and work like all the rest of your apps.
2 Likes
Just did it after commenting here. It would be way better to have support for .rpm too. But .deb has been the stand for a long while which we can’t change.
I just hope flatpak replaces everything and these native package formats should be confined to mission-critical apps that require host resources to be accessed directly and system packages.
I have not run into this issue. Very frequently there are Flatpaks available, like Signal’s.
It isn’t official and made by community, how would you trust it ?
Off-topic : The site returns 404 not the forum.
I wouldn’t trust it + you don’t know if it will function correctly because Flatpaks aren’t officialy supported.
The reason, I am sticking to official packages as far as I can and are now mitigated by distrobox in the case of unavailability. I thought of using toolbox by Red Hat, but it doesn’t provide an easy way to export app shortcuts. So, sticking with Distrobox by podman.
You are right, and you shouldn’t trust unofficial flatpaks without some due diligence.
If you have the requisite knowledge you can read the flatpak manifest file to see how it is built, depending on the flatpak, it can be pretty straightforward or a little complex. In the case of Signal it’s somewhat simple/easy to understand. But I do hope that Signal picks up support for the flatpak at some point. Currently I don’t use Signal desktop, but when I did, I used toolbox or distrobox to install the debian package.
1 Like
So, checking the manifest file for its source URL is better if it is really necessary or the only way ?
Its at least a step in the right direction/better than nothing, and most importantly is something I’m actually capable (partially) of doing and feeling somewhat confident in my ability to understand.
I don’t consider it sufficient but my basic due diligence for unverified flatpaks that I consider a risk is (1) check the manifest, (2) spend a few minutes trying to learn a bit about the reputation/affiliations of the unofficial/unverified maintainer, the community opinion. Its not perfect but its better than nothing.
In cases like Signal or Bitwarden, the manifests are somewhat simple, but its not always that easy to interpret
I subscribe to the GitHub releases to give me an email notification and I used to do compiling myself with an AppImage as an output. I think you can also do an RPM as an output but I havent tried that yet.
1 Like
Woah, that’s really messy. No way, I could understand that quickly.
Messy for workflow. I am with distrobox now. So, a simple update script will take care of everything and I am using podman. So, it’s rootles too.
1 Like
I’ve only recently seen distrobox in action and had I known that, I would have used that method.
Depending on what you are trying to do, I think this functionality is already built into distrobox (I use the command distrobox upgrade --all for this purpose (it upgrades all distrobox containers). For more info/options: man distrobox upgrade)
1 Like