The only thing the hardcoded assertions key currently enforces is that each snapd instance is only connected to a single snap store. A different distribution like Manjaro could very well ship a modified snapd to their users which points at their own store. Manjaro chose to use the snap store hosted by Canonical because they like the advantages that gives them. This is no different from how Linux Mint used to point apt on their devices to the Ubuntu repo’s in the beginning and switched to their own repo’s after a while. Manjaro will be able to switch to their own snap store if that makes sense to them. Note that this is exactly what the Ubuntu Touch project did. They are using “click”, the precursor to snap, and they created their own store and Canonical helped them with the transition from the Canonical store to their own store.
So I strongly disagree that “any open-source 3rd-party effort is pointless”. Snapd is a great package manager and any distribution can take advantage of that, just like they already do with apt.
However, in this context, there are two limitations in snapd that apt doesn’t have:
- There is no user-accessible config to change the snap store. This is something that would be trivial to add to snapd if people are interested in running other stores, though this feature would need a lot of design work to make sure that the user experience of switching to a different store is good. For example: what happens with the already installed snaps? Given that on some devices, the kernel itself is also a snap, this is an important issue to solve before making it possible for users to change this.
- Each device can only use a single store at one time.
The second point was a conscious design choice by the snapd developers with two main motivations:
- The first motivation is that having only one store per device solves a lot of the user experience issues that ppa’s have. Note that this is not “everyone using snap should use the Canonical store”. What they actually want is “every device using snap should only use a single store”, regardless of who runs that store. Canonical’s experience with ppa’s showed them the disadvantages of having each device connect to multiple separate “stores”. Flatpak is currently experiencing the same issues; hence their push to get as much apps as possible into Flathub, instead of each publisher hosting their own Flatpak repo like they did in the beginning.
- The second motivation is that having only one store makes a lot of stuff easier to implement. The snapd developers have not implemented this functionality to make their jobs a lot easier. Though on this forum some snapd developers have showed that they are open to the idea of someone else adding this functionality to snapd. They will simply not add it themselves.