[GH-ISSUE #22] provide snap package #70

Closed
opened 2026-03-01 17:44:32 +03:00 by kerem · 5 comments
Owner

Originally created by @jeroenev on GitHub (Feb 9, 2020).
Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/22

Snap packages are becoming more and more popular, especially on Ubuntu. Some apps like NextCloud already have a snap version available.

Having a Snap package like NextCloud has, would massively simplify the process for self-hosting.

Originally created by @jeroenev on GitHub (Feb 9, 2020). Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/22 Snap packages are becoming more and more popular, especially on Ubuntu. Some apps like NextCloud already have a snap version available. Having a Snap package like NextCloud has, would massively simplify the process for self-hosting.
kerem closed this issue 2026-03-01 17:44:32 +03:00
Author
Owner

@chiraag-nataraj commented on GitHub (Feb 9, 2020):

Honestly, it's probably better to get anonaddy into the major repos, mainly so that it can use packages that are already installed in the system. I wish Snap and Flatpack and the rest properly solved the redundant dependency problem, where you have n copies of a dependency if you have n snaps or flatpacks that depend on it. I don't understand why everyone thinks it's a good idea to bundle dependencies like this...it creates much more work for the developer, who now not only needs to stay on top of security holes and bugs in their software, but also has to stay on top of security holes and bugs and stuff in their dependencies! The modular nature of Linux repos solve this issue quite well, and to whatever extent they have problems (the proverbial "dependency hell"), those can be solved by e.g. adopting better versioning mechanisms, loosening restrictions on versions in packages, and so on.

I know it's entirely off-topic, but there's my rant on snaps and flatpaks. It would be far better to have a universal packaging format, more consistent package naming systems, and so on so that you could build a package, quickly create a repo, and know that it will work on most up-to-date distros.

So yeah, please don't create a snap or flatpak. It would be far more productive to build packages for various distros and either run a set of repositories or get those packages accepted into various distros.

<!-- gh-comment-id:583909810 --> @chiraag-nataraj commented on GitHub (Feb 9, 2020): Honestly, it's probably better to get `anonaddy` into the major repos, mainly so that it can use packages that are already installed in the system. I wish Snap and Flatpack and the rest properly solved the redundant dependency problem, where you have `n` copies of a dependency if you have `n` snaps or flatpacks that depend on it. I don't understand why everyone thinks it's a good idea to bundle dependencies like this...it creates _much_ more work for the developer, who now not *only* needs to stay on top of security holes and bugs in their software, but *also* has to stay on top of security holes and bugs and stuff in their dependencies! The modular nature of Linux repos solve this issue quite well, and to whatever extent they have problems (the proverbial "dependency hell"), those can be solved by e.g. adopting better versioning mechanisms, loosening restrictions on versions in packages, and so on. I know it's entirely off-topic, but there's my rant on snaps and flatpaks. It would be _far_ better to have a universal packaging format, more consistent package naming systems, and so on so that you could build a package, quickly create a repo, and know that it will work on most up-to-date distros. So yeah, please don't create a snap or flatpak. It would be far more productive to build packages for various distros and either run a set of repositories or get those packages accepted into various distros.
Author
Owner

@jeroenev commented on GitHub (Feb 10, 2020):

@chiraag-nataraj I can understand your POV. But the same thing can be said for any container technology, the same thing applies to docker where they provide a full linux distro in the containers.
it definitely adds to storage space and makes developers manage more dependencies. creating deb/rpm packages works but after installing many of them there's always 1 with a dependency issue or one that hasn't been updated for the latest release of ubuntu/fedora/whatever.

<!-- gh-comment-id:584063873 --> @jeroenev commented on GitHub (Feb 10, 2020): @chiraag-nataraj I can understand your POV. But the same thing can be said for any container technology, the same thing applies to docker where they provide a full linux distro in the containers. it definitely adds to storage space and makes developers manage more dependencies. creating deb/rpm packages works but after installing many of them there's always 1 with a dependency issue or one that hasn't been updated for the latest release of ubuntu/fedora/whatever.
Author
Owner

@anonaddy commented on GitHub (Feb 11, 2020):

I don't know anything about making snap packages etc. so won't be able to assist in this for the time being.

I'm currently writing a rough full guide on how to self host AnonAddy so hopefully someone else with more expertise in these areas will be able to follow the guide and look into setting it up.

I completely agree though, it would be great to have an easy way to self host the service.

<!-- gh-comment-id:584549924 --> @anonaddy commented on GitHub (Feb 11, 2020): I don't know anything about making snap packages etc. so won't be able to assist in this for the time being. I'm currently writing a rough full guide on how to self host AnonAddy so hopefully someone else with more expertise in these areas will be able to follow the guide and look into setting it up. I completely agree though, it would be great to have an easy way to self host the service.
Author
Owner

@chiraag-nataraj commented on GitHub (Feb 15, 2020):

@jeroen7s Containers are different, though, right? Like, the whole idea of containers is to be self-contained, as it were. And, crucially, since containers like Docker provide a full OS, you can use the normal packaging tools to deal with dependencies as you would with a 'regular' computer. This is in stark contrast to something like flatpak, which does put more pressure on the developer.

@anonaddy, yeah, I think if you could write up that guide, someone could probably help create deb and rpm packages (the "big two", as it were) and we could take it from there. I'm more than willing to help with creating the deb packages, for example (I use Debian).

<!-- gh-comment-id:586640741 --> @chiraag-nataraj commented on GitHub (Feb 15, 2020): @jeroen7s Containers are different, though, right? Like, the whole _idea_ of containers is to be self-contained, as it were. And, crucially, since containers like Docker provide a full OS, you can use the normal packaging tools to deal with dependencies _as you would with a 'regular' computer_. This is in stark contrast to something like flatpak, which _does_ put more pressure on the developer. @anonaddy, yeah, I think if you could write up that guide, someone could probably help create `deb` and `rpm` packages (the "big two", as it were) and we could take it from there. I'm more than willing to help with creating the `deb` packages, for example (I use Debian).
Author
Owner

@willbrowningme commented on GitHub (Dec 2, 2020):

I'm closing this for now as I don't have the knowledge on how to create a snap package.

<!-- gh-comment-id:737135881 --> @willbrowningme commented on GitHub (Dec 2, 2020): I'm closing this for now as I don't have the knowledge on how to create a snap package.
Sign in to join this conversation.
No labels
bug
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/anonaddy#70
No description provided.