How to remove completely Snap, Flatpak and Appimage* from Manjaro?

[Macciolo]

Is it enough for snap to use sudo pacman -Rscn snapd or there is something else that is related to snapd that should also be removed? A service, process or some other hidden package? I see someone mentioning about apparmor is related to snapd.
I want to remove flatpak as well.
I am not sure about AppImage*, and if there is some package installed to make it "work".

I am aware that unfortunately Manjaro is shipping snap and flatpak... Apparently, everyone is giving in to Canonical's and Red Hat's wishes. Hasn't systemd been enough?

[jonathon]

Is it enough for snap to use sudo pacman -Rscn snapd

Yes, though there may be the snap files themselves left in /var/lib/snap depending on how the package is structured.

You can check the full list of installed files with pacman -Ql snapd

I want to remove flatpak as well.

Same thing, -Rncs gets rid of most stuff.

[firefightux]

I also do not use any of these, but I feel some points need a little bit of additional information.

I am aware that unfortunately Manjaro is shipping snap and flatpak

AFAIK, only the 18.1 iso series will ship snapd installed by default. Any older has snapd not installed by default. I am not aware of flatpak or appimage installed by default in any version. You just have the option to install them, but you have to install them yourself.
To remove the snap support services for 18.1 series see:

Does anyone actually use snaps?

As Manjaro only provides the foundation any complaints on app functionality or lack thereof is the developer(s) of said app. This has always been so. For the users concerned of the default enabled services - they can be disabled using sudo systemctl disable apparmor snapd.apparmor snapd Before doing so I would recommed knowing exactly what you are doing.

I see someone mentioning about apparmor is related to snapd.

AFAIK apparmor is required by snapd for sand-boxing

Concerning apparmor:

apparmor

The new systemd (242.29-2) in unstable also depends on AppArmor. The package does not list AppArmor as a dependency, but the version string shows +APPARMOR . And at least systemd-analyze will not work without libapparmor.so.1 . Maybe it is a good idea to add apparmor at the list of dependencies for systemd. I'm not a fan of snaps, but I like the idea of a bit more security directly build in. The original Arch firejail package already depends on AppArmor. Even Arch has AppArmor support in the…

Dbus does not depend on apparmor anymore see:

[DBUS] [Testing] Dbus update on testing, breaks dbus, and login (dependency for libapparmor.so.1)

After upgrading to testing, I ran into the following problem (from journalctl) Login was broken, (fixed with appending 3 to boot parameter) and downgrading d-bus package from dbus-1.12.16-1.1 to dbus-1.12.14-1 Just wanted to let you know of this issue, as seen in the pasted log, it is because of an libapparmor.so.1 dependency which apparently was not installed.. Jun 27 11:29:32 jonas-linux-manjaro kernel: audit: type=1130 audit(1561627772.893:10): pid=1 uid=0 auid=4294967295 ses=4294967295 ms…

[linux-aarhus]

I am aware that unfortunately Manjaro is shipping snap and flatpak... Apparently, everyone is giving in to Canonical's and Red Hat's wishes. Hasn't systemd been enough?

You can't keep living in the past.

And I don't see it as giving in - I see it as consequence of the ever evolving Linux eco-system.

For years people have been complaining that Linux is not following the tide and when Linux does - users start complaining about the good old days.

You cannot satisfy everyone.

If you want a true Free system - you could always use Parabola - they even do an openrc version.

[Macciolo]

It is not like "living in the past", it's more like "using what works better", that is = Repos.
I have already used and tested both snap and flatpak and have had more cons than pros with them, so I decided keep using so hated 'old way' of doing things. That's it.
When snap and flatpak became more mature and less problematic, maybe I'll give them a second chance.

[linux-aarhus]

It is not like "living in the past", it's more like "using what works better", that is = Repos.

I agree.

It should not be snaps for sake of snap but for a viable method of running apps which can be otherwise problematic.

E.g. Skype - which I never use but a new client wanted a skype call from an office in Germany.

I know I don't want to infect my system with a probably troublesome version from AUR so I activated snap

systemctl start snapd snapd.apparmor appmor

The next thing was

snap install skype --classic

And it worked - no issues. Now that was useful - getting paid to meet with with Ruby developer in Germany using Skype. I can live with snap for such usecase.