Hi.
I’m building a snap based on the kde content snap.
Can it or the soon to arrive kde-neon extension be set to auto-connect?
It’s a bit complex to ask users to install and connect the content snap.
Thanks
Autoconnection is granted on a per-snap basis so you need to ask permission for the client app specifically …
Thanks for the reply
Is the gnome content snap not automatically connected by default?
If I add the gnome content plug (or the new gnome extension) it automatically gets downloaded and connected.
Should it not be the same for the kde content snap?
hmm, perhaps something has changed, but i think even the gnome content snaps auto-conncet because the apps have been set up for this … i added this post to the store category so it shows up in the right queue and the store team can comment…
Thanks. Reading this I thought that the idea was that the gnome content snap autoconnected because it was considered safe. So if I use it in a snap I don’t have to ask for an auto connect. I have a snap that’s not yet in the store, and if I install locally it auto installs and auto connects the gnome interface.
IIUC, what was done for gnome content snap is a global snap-declaration allowing any snap to use default-provider: gnome-3-28-1804 in the plug and that would automatically install the gnome-3-28-1804 snap if one published a snap with that default-provider spec.
I think what’s being requested here is the same thing for the KDE libraries content snap.
Making the extension include this default-provider AIUI would be dependent on granting the default-provider auto connection.
Yes, that’s what I meant.
I had no idea that’s how it worked, but that’s the sense of it…
I was wondering if the default-provider was intended to have the same use in all the extensions.
Or at lease the “base” ones, like gnome, kde, …
Thanks
I moved this to the #store-requests category in that case
1 Like
While this is true, as @ijohnson points out, the publisher of the content providing snap can also request a global connection. The publisher can follow the process as described here: Process for aliases, auto-connections and tracks - #11 by jdstrand (perhaps reading the thread starting here for additional context).
1 Like
Can you request auto-connection for the kde-frameworks-5-core18 content snap so that apps using the upcoming neon extension work out of the box?
1 Like
This seems to be stalled, doesn’t it?
What’s the main reason for content snaps to not autoconnect anyway, at least for read-only paths? I presume it’s the vetting of the publisher and ensuring that good practices are employed. The risk is rather small if both parties (consumer & producer) explicitly declare their intent, I think. Nothing prevents me from shipping any libraries, runtimes etc. myself anyway.
Yes. I think the next step is for the kde-neon devs to request auto-connection for their kde-frameworks snap, just like the Ubuntu devs did for the gnome-3-28-1804 snap. I contacted the KDE-neon devs yesterday to ask them to do this. Last I heard they would discuss this internally but they seemed open to the idea.
Correct, that is the current system; consumers declare their intent by using the plug in their snap and setting the default provider. Producers declare their intent by requesting a global auto-connection.
The key thing to keep in mind is that interfaces are essentially contracts between the provider (slot) and the consumer (plug). We allow the content interface to be auto-connected when the provider and the consumer snaps both come from the same publisher since the publisher can ensure that changes in the provider don’t break the consumer(s) or can change the consumer(s) as needed for changes in the provider.
When the provider and the consumer come from different publishers, this is not possible and there are no technical guarantees in snapd to ensure that the provider won’t break consumers, but we want the ecosystem to flourish and be reliable. We therefore have store processes for auto-connecting content interfaces across publishers (including global auto-connection) which, among other things, requires that the providing snap’s publisher agrees to not intentionally break consumers (eg, by removing APIs, file, changing ABI, etc). Put simply, the limitation is in place to help protect consuming snaps from breaking due to changes in the provider.
2 Likes
Would it be correct to assume that auto-connect isn’t relevant for classic snaps? i.e. classic snaps are already able to access anything they need to, right?
unless it recently changed, classic snaps can not use interfaces at all so auto-connect is moot in this case …
1 Like