extension-manager
extension-manager copied to clipboard
mjakeman
support for snap
by default ubuntu supports snap without install but for flatpak it is not supported by default and you have to install flatpak manually.
Yes, the situation on Ubuntu is not ideal at the moment. Snap support is planned, although definitely not before v0.3.
For the mean time, I'd recommend just using the flatpak. When GNOME 42 launches in a few weeks, we should be able to cut the flatpak install size down by quite a bit as libadwaita & friends will be included in the runtime.
Hi, @mjakeman ! Is still something missing for a snap version being released? I tried to build it using snapcraftand everything seemed to work fine (I only needed to change source . to source github.com/... and to add a source-type, but I believe it was needed only because I'm not building it using snapcraft.io). Weel, if there's anything I can help with, let me know.
Hi @santiagofn, everything is in place for the Snap package (thanks to @dingdang66686 for his contribution), I just need to tag and release v4.1. Unfortunately I've been very busy lately so it'll be a few more weeks until I get around to that.
@dingdang66686, apologies for leaving this so late, but would you be able to add me as a collaborator to the existing gnome-extension-manager snap package? My email is mattjakemandev <at> gmail.com.
@mjakeman I have invited you in the snapcraft website. Please accpet. 😁
I've been looking into a lot of recent failures with the snap package (#424, etc) and stumbled upon this forum thread (I believe this was you @dingdang66686)
https://forum.snapcraft.io/t/my-snap-cannot-interact-with-gnome-shell-extensions-dbus-interface/33573
Considering that the Snap team does not want to support org.gnome.Shell.Extensions with classic confinement, I wonder if we should consider delisting the gnome-extension-manager snap on the website and only support it through devmode.
It's generating a lot of issue volume for a relatively small install base, and I also think we shouldn't publicly distribute something that doesn't work fully out of the box. Instead, we should provide snap files but make it clear that the user must install it themselves (to avoid broken confinement related problems).
Does this sound like a correct summary of the issue? What does everyone think of this?
Uhm, this comment specifically makes it pretty difficult to keep the stance "a snap version should be supported".
Uhm, this comment specifically makes it pretty difficult to keep the stance "a snap version should be supported".
I fully agree. I've had some more time to think about it, and I don't believe snap is something we should or can support.
To be a bit more clear, there is a working snap package (the one distributed in this repository).
It works with classic confinement, which is the same confinement level used by tools like IDEs. However the snap team have made it clear this wouldn't be distributable via the snap store for the reasons mentioned.
There is also a package already on the snap store maintained by @dingdang66686. The initial plan was to take this over as an official package (#314), but it's clear that this will not be possible given the limitations above. While I appreciate third party package maintainership, I also think it's very important to avoid shipping broken packages. Therefore, I will have to ask you @dingdang66686 to de-list the snap store package if a solution cannot be found. We shouldn't ship broken software to users.
Secondly, I would like to consider deprecating the snap files in this repository. I think, if we can't distribute it (and the response from the snap team seems pretty clear cut) there is a limited use in having a classic contained snap.
It's theoretically useful for more technical users, but I'm not sure the userbase is large enough to keep it in-tree. I'm most grateful for your contribution @dingdang66686, but I think snap is unfortunately the wrong package format for a tool like this.
However, I would like to hear your thoughts before making any immediate decision.