Manjaro planning to support snaps officially?

As far as I know, nobody is talking about taking anything away or forcing snaps instead of the methods you are already used to. Just adding one more tool in the toolbox available by default.

3 Likes

Yup. I think I covered this earlier in the thread, but just to say it again:

"Officially supporting Snaps" doesn't mean "Snaps are the only thing."

At the moment, the Snapcraft documentation says to "install from the AUR". Supporting it "officially" will help change that to say "install from the repo".

There may be an edition down the line which includes Snapd by default but like all preinstalled software it will be trivial to remove, there would still be the Architect installer and Minimal profiles, and if there was ever any impetus for such a "snap included" edition then I'd argue for a "standard" edition too - or have it as a installation-time/post-installation option (e.g. in a "first run" setup application).

However: this is all speculation and hypothetical. Nothing has happened yet, nothing is planned, and, as everyone on the forum should already know, Manjaro is here to meet the needs of the Manjaro community. It's why I got involved in the first place: to prevent things going the way of Ubuntu and e.g. its Amazon Lens. I believe I've already shown I will speak up about things I don't agree with so there is no "group-think" here.

10 Likes

Basically, we all all a bunch of little gossip-whores. (Condensed Version)

2 Likes

201ms var-lib-snapd-snap-snap\x2dstore-60.mount
194ms var-lib-snapd-snap-gtk\x2dcommon\x2dthemes-1198.mount
191ms var-lib-snapd-snap-superproductivity-191.mount
190ms systemd-journald.service
172ms var-lib-snapd-snap-gnome\x2d3\x2d28\x2d1804-36.mount

Snap is near the bottom of the list, like I thought. Network manager is the highest; 6.391s NetworkManager-wait-online.service.

First question should be:
Do Snaps actually make sense over AUR packages?

This is going off-topic. Discussion about the relative merits of Snaps can go in its own thread.

3 Likes

I don't use them, but as they say in this thread, NOT supporting it doesn't really make any sense.

1 Like

Having Snap and Flatpak support in Pamac would be a good start. Especially important for Flatpak as there's no auto-update mechanism otherwise... (You have to use something like KDE Discover or GNOME Software.)

Always prefered flatpaks. Anyways thats right it will be good start point!

1 Like

Out of curiosity I have installed the Epiphany browser as a Snap (the "latest/edge" version 3.33.1-5aaccc83e, development build). The package builder is Jeremy Bicha and I think he is a well known and highly competent developer working for Canonical. The browser is running extremely fast and stable in comparison. So there is no need to delete this Snap, I am convinced. If other Snaps work like this I am happy and hope that Phil will enjoy his trip to Montreal. There are big advantages if a cooperation with Canonical grows up. Nobody is forced to use Snaps, it's just a service.

While the Snaps & Flatpak idea makes sense and would likely allow more developers to support Linux without fear of dependency hell & broken package managers, distros like Arch & Manjaro shouldn't default to them. The current system works wonders, it's actually one of the best package managers I've ever dealt with.

Now, does this mean that Manjaro shouldn't support Flatpak/Snap? No, I think the community should support it as an alternative install method. Some packages are better when packaged as an all-in-one software (especially closed-source software) bundle.

Personally, the only Flatpak software I have is the Zoom conferencing software because the AUR package is broken because of the dependency breaks the software, Flatpak fixed the issue because it has the correct libraries.

Having Snap and Flatpak support in Pamac would be a good start. Especially important for Flatpak as there's no auto-update mechanism otherwise... (You have to use something like KDE Discover or GNOME Software.)

There is an updating mechanism but it has to be done on the command line if you don't have the GNOME Software Centre or the KDE Discover app installed.

The command to update your flatpak software is:

flatpak update

even easier would be using a pacman hook. when you update your system, your flatpaks get updated at the same time without need of even more software to manage it.

2 Likes

Maybe someone should write and package it? Pkgname flatpak-update, post-update hook that just runs flatpak update? does flatpak update need to run as specific user or without sudo privleges?

1 Like

Since I'm not familiar with it at all, could that be helpful?

cant remember, i've used flatpaks/snaps in the past but removed not long after seeing how much space they take up.

seems like the most logical thing to do since every arch/manjaro user has pacman installed regardless of DE/WM. something like this

#/usr/share/libalpm/hooks/flatpak-update.hook
[Trigger]
Operation = Upgrade
Type = Package
Target = *

[Action]
Description = Updating flatpak's
Depends = flatpak
When = PostTransaction
Exec = /bin/sh -c 'flatpak update'
AbortOnFail

if flatpak update needs to be run as user and not root, the Exec = line needs some editing

To download the package, no. But to install it, yes, need. (like an AUR helper)

yes. I've tested your hook and the Flatpak's package just will be updated when running the AUR helper (without root). I got two question:

  1. Is AbortOnFail necessary is this case, since this one is used only for PreTransaction? alpm-hooks.

  2. The hook will just run if, and only if, I got AUR packages to update? Because the hooks isn't running since I got none AUR update. Because right now I have no AUR package to update and the hook isn't running.

someone more knowledgeable with hooks should probably answer that, i know just enough to not know the answer your question :sweat_smile:

2 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by