I know this is a big question but, what is going to be the position toward patches that allow tools and other parts of the ecosystem to play nice with other stores?
Let’s, for the sake of argument, leave off changes to snapd that give it other trusted accounts. But aside from that what about patches that would make it easier to where if you had a patched snapd that it would work nicely with everything else.
This issue I’m facing at the moment may not even be an “issue” but it got me thinking about this question generally.
So I’m trying to install Snapcraft into a Docker image and I noticed these lines:
=> Installing the Snapcraft snap
==> Checking connectivity with the snap store
Which strikes me as odd (in some ways) for a couple of reasons:
Right now I don’t care whether snapcraft can reach the store and it shouldn’t either, I’m building a Docker image that could be used later, or whatever.
It’s installing the snap when I originally was installing it from apt (this is the part that’s actually less surprising to me but might surprise other people)
And, again this specific issue may not be an issue and if there’s an easy way to fix this the please let me know that too.
But otherwise the bigger question remains: should I just plan on forking / re-implementing instead of trying to “keep everything intact”?
The line “==> Checking connectivity with the snap store” is used in a number of packages where the deb has been deprecated in place of the snap. Off the top of my head lxd, snapcraft and chromium are examples of this.
The “I don’t care whether snapcraft can reach the store” is missing the fact that it’s not snapcraft itself trying to reach the store in this case, it’s the snapcraft.preinst maintainer script in the transitional deb which is doing the connectivity check so it can install the snapcraft snap from the store.
The reason it appears is because you’re building a docker image in which you want snapcraft, and the origin of snapcraft is the snap store. So it’s perfectly reasonable for that message to be emitted, given the thing you asked it to do.
No, you’re absolutely right. I missed a few important question marks in my punctuation. I’ve corrected the original post but restate them here for further discussion:
What is going to be the position toward patches that allow tools and other parts of the ecosystem to play nice with other stores?
Should I just plan on forking / re-implementing instead of trying to “keep everything intact”?
And also, to be clear, I don’t necessarily have a patch today as I’m describing. I just thought it was important, at least to me in my current development, to visit these questions explicitly and sooner than later.
I don’t want to spend a lot of time working on interoperability for the sake of interoperability if it’s just causing me pain.
Edit:
wanted to add note about the “interoperability” - that was explicitly in reference to the store and getting things in and out of the store, management, etc. Of course interoperability with snapd and snaps generally speaking is the goal
For what it’s worth it would be a lot of work for the snapd team to add proper support for other stores at this particular moment, so even if you had a full patch set to send upstream, it would probably not get reviewed because there are other implications for i.e. the store side of things. Not trying to lean you one way or the other, just that your patches supporting multiple stores to snapd would probably not get merged for quite a while if you opened it right now
I imagine a lot of the burden this would put on the snapd devs is in ensuring that snapd continues to operate given unusual responses from third party stores. Now it can be assumed that the store and snapd are in lockstep with each other and the only issues to account for are connectivity to the store and the store failing to return the expected result. When third party stores are in the mix then snapd needs to account for the third-party stores potentially sending malicious responses and otherwise incorrect data. To be truly angnostic snapd needs a TON more testsuite coverage to account for the weird and wacky ways that a third party could behave.
