Reopen issues relevant to packaging as snap and flatpak. #2098
Replies: 1 comment
-
My position on this has been really clear:
I will not be developing a snap or flatpak for this client. I will not be reconsidering any request to do do. Strongly suggest that if you want to see a snap and/or flatpak for this client then please learn and develop these yourself and contribute those efforts back to the Open Source community. I have zero desire to develop or maintain any package for this client (outside of a Docker image) for any distribution. Additionally the client has already been packaged for many distributions as per here: https://repology.org/project/onedrive/versions - so you can easily install the client on your chosen distribution with a minimum of fuss. The outlier here on packages is Debian, Ubuntu and distributions based on these - simply because of their packaging policies & process. This is why the OpenSuSE Build Service repository exists to provide up-to-date client versions for those distributions. Additionally, specifically regarding 'snaps' - Snaps use a back end that is totally is proprietary, controlled entirely by Canonical. If you want to release your program as a snap, Canonical has to approve. If they at any point change their position - poof its gone. Additionally snaps historically, they're slow, bloated, and handling permissions is a pain. This client relies on accurate permissions and filesystem access to operate. My primary aim is to provide a quality client that folk can use, that is relativity bug free and has great documentation to help folk use it. |
Beta Was this translation helpful? Give feedback.
-
"skilion/onedrive#313 (comment)" demonstrates that what "#927 (comment)" and "#2072 (comment)" state is incorrect, because
snap
is designed to support commandline software, andflatpak
supports such software too, albeit slightly less well.Consequently, I propose that the current stance be reconsidered.
2 votes ·
Beta Was this translation helpful? Give feedback.
All reactions