-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Snap releases #8688
Comments
I'm not from PL, but I think Snap was supported because it is the default package manager on Ubuntu, and it was hard to put in on apt which also installed by default on Ubuntu and more commonly used, IIRC. |
I had a ton of random issues with the snap package on my wife's ubuntu laptop. Finally gave up and used the binary release which worked fine. |
Agreed that there are issues with Snap. We could ask Canonical to get us approved for classic. If there are README updates you'd like to make to add clarity beyond what's there that's fine too but things seem documented already. None of the package mangers are explicitly supported by go-ipfs and are mostly community maintained. If there's a simple CI action we can use to deploy to a package manager then we do that to make life a little easier. However, whether we automatically publish a Snap or not someone else will and we'll end up with support requests anyway (IIUC the go-ipfs snap was previously community run before we had a CI action). |
fwiw i filled request for classic in https://forum.snapcraft.io/t/ipfs-classic-request/28516 |
Reopening just to track the snap switch to classic mode. Brief summary:
|
Confirmed - IPFS_PATH fails to get passed through and the binary fails without explanation. |
BTW, it's perfectly reasonable to use another install method, because IPFS requires so little - crates, debian - even a bash script - is preferrable to me. |
I’d like to note that every time Snap discussion surfaces every few weeks, it ends up being a time sink and Snap maintenance creates a disproportionate burden to everyone involved (snap has ~4k users). ipfs-cluster got granted Unless someone familiar with Snap wants to step up and drive this forward, I suggest we limit the time sink caused by Snap, pased on result of this thread:
|
@lidel Any update on getting |
Snap has been a dumpster fire lately. Is there even any real demand for Snap packages anymore? Flatpak is in use on most of the distro's i'm aware of. Gnome software manager even dropped support for Snap due to the ongoing issues with it and lack of maintainers. Pretty much anyone using Ubuntu (and really buying into the ecosystem) is going to grumble about missing snap packages... however the rest of Linux distros moved on from Snap a long time ago. |
It's a shame there's no Flatpak, last time it was discussed that I know of was ipfs/ipfs-desktop#686 |
There is no progress on getting As noted in #8688 (comment), I am unable to invest more time into this time sink: it burns a disproportionate amount of time given relatively low user count (https://snapcraft.io/ipfs has ~3-4k weekly active users, while our browser extension alone has >60k). My vote is to remove it – dev time can be better spent in other places. We could nuke it like https://snapcraft.io/ipfs-cluster got removed in ipfs-cluster/ipfs-cluster#649, or we could do this gently, by publishing a binary that prints "Snap is no longer supported, see https://docs.ipfs.tech/install/command-line/#linux for alternative installation method". Don't feel strongly either way, would like to hear what others think. General digression: I am using Linux myself (running Kubo in Docker). There is a long tail of Linux package managers. They all are great and terrible in their own unique ways and it is the best if people familiar with them spend time on producing packages. Kubo produces prebuilt binaries as Docker images and a generic I opened #9239 to make it clear that everything other than Docker and https://dist.ipfs.tech/#kubo is unofficial. |
2022-09-02 maintainer conversation:
|
Here's the plan for completing this issues:
Here's the proposed deprecation text:
|
Kubo is no longer distributed through Snap. |
Checklist
Location
https://github.com/ipfs/go-ipfs/blob/master/README.md
Description
Although not extremely numerous, IPFS issues related to Snap appear somewhat consistently with new users, a containerized format does not mesh well with IPFS's capabilities and use-cases, it also doesn't help that the errors produced by Snap installs are very vague which makes troubleshooting difficult. This could be partially solved by recommending
snap install --classic ipfs
to eliminate some of the issues, however, I propose a more substantial workaround. Removing Snap altogether.Deb and RPM packages would be a much more useful alternative to Snap in a number of ways, they are more common place than Snap and do not require a secondary package manager to be installed, go-ipfs already provides a
tar.xz
release (ipfs/ipfs-desktop#691 (comment)) so moving to Deb and RPM shouldn't require too much effort (Also see #5471).I'd particularly be interested in hearing from someone in the IPFS team to find out why Snap was chosen originally to give insight into this.
(Sorry in advanced if
docs
wasn't the right category for this issue, none seemed more appropriate for packaging-related issues)The text was updated successfully, but these errors were encountered: