Order of personal preference.
- Repo.
- Compile and package myself.
- flatpak.
- appimage.
Some things are just too time consuming to compile and troubleshoot issues that occur every major release . While I don't use chromium
itself, it as an example of something that can be a real PITA and if I could avoid it I would. But I have to deal with it for ffmpeg-chromium
, just extracting the source alone is 6-8mins. firefox
is so much easier. </rant>
This includes things that might be simple to compile themselves but:
- Require too many dependencies that Solus does not already have.
- Are poorly documented.
- Have extremlely slow or stalled development that makes maintaining it harder as it becomes incompatible with newer versions of its dependencies, slowing down stack upgrades or requiring packaging multiple versions.
- Horrible build systems with crap error reporting making a package maintainers life more difficult than it need be.
So when the above is an issue or it is a proprietary application this is when universal package formats come into play for me.
Flatpaks
If you are going with a non natively built package. Flatpaks are just going to be my first choice, I have no issues with them.
Appimages
I use one for curseforge
(WoW addon manager) but its only as a last resort. They have no .desktop file integration OTB and a built in update mechanism is not a guarantee. curseforge
will update itself but most appimages don't in my experience.
There are also weird issues where certain libraries are excluded from appimage creation, making it a not so universal packaging format.
Snaps and Solus Third Party section.
I have not used snaps in about a year or so, maybe things have improved a little since then but they create loop devices for every package that are mounted on boot; This can significantly impact your boot and shutdown time and can be slower to launch compared to flatpaks.
They have also been more problematic from the distro side of things for maintainers. It uses AppArmor for strict confinement and there has been seemingly little movement on getting their patches unstreamed into the kernel. Kernel 6.6.x requires 78 patches.
Then there is the patching required for snapd
itself for Solus. This can create delays waiting for patches and/or diverts teams resources.
Solus intends to deprecate snap support.
We have also had a long... long term goal of deprecating our Third Party section of the software center which is for applications we can not legally redistribute due to licensing restrictions. So I would avoid using that too.