Historically this comes down to the way snapd handles these overrides; by adding gimp-plugins the other GTK components lose their autoconnection status. The store can amend this their side to explicitly add the Gnome content snaps to the custom interface assertion and recreate the default logic.
It’d be nice if snapd could handle this better because it feels like this issue catches people by surprise a lot. For GIMP, if you rebase on e.g., Core 26, you’d want to validate this again against the new content interfaces.
Explicitly you won’t see this issue with a local unsigned build because the problem is actually the assertion itself changing the autoconnection logic, lacking the assertion entirely means you get the Gnome extension stuff properly.
I think the ideal fix for yourselves is the store amends the assertion so that everything is autoconnected properly and then GIMP separately releases a new revision ( even just to bump the timestamps ) and releases that; then users who may have installed with the old assertion (with the plugins defined) will have their GIMP fixed by the new one.
gimp-plugins is the above request, npu-libs I haven’t seen requested yet and would check on (but believe it’s some of the previous snapcrafters work that would have already been approved - yet if they were, these other connections would already be in place; so perhaps not?) - the rest are from the Gnome extension and would automatically connect by default so are uncontroversial when this situation has occured in the past.
Having checked the cups plug, since it isn’t a content interface, it doesn’t seem to have any issue with autoconnection to the cups slot from the CUPS snap and the other interfaces look fine too. Worth mentioning to the GIMP devs here however that cups will only connect automatically if the CUPS snap is installed; so to cover all bases, GIMP should separately tweak their snapcraft.yaml to define CUPS as the default provider of CUPS shown here - which will ensure it’s installed alongside with GIMP.
Hey folks! I think @James-Carroll is right, I just reverted the last change and I expect gimp to work again for new installations. I’ll take a look asap on how to properly handle the auto-connections to the gimp plugins.
Let me know if the issue if fixed now and I’ll keep you posted
For a bit of extra context see GIMP auto-connection to theme snaps. As discussed in that thread, either we keep gimp snap-declaration updated with every content snap used by gimp or we make the update in the snap-declaration for each independent gimp plugin snap.
In the first case, we will need to update gimp snap-declaration every time the snap plugs a new content interface (even those that were granted with global auto-connection in the past). With the second option we will need to create a snap-declaration for each gimp-plugin that requires auto-connection.
@GIMP what option sound better to you? What is you expectation in terms of amount of gimp plugin snaps?
Hi, @jslarraz. If we understood correctly, the first option is something to be done on snapcraft side regarding gimp snap? Or it is something that we need to do with our snapcraft.yaml file?
The second options is not doable. We can’t predict how many plugins will be out there nor require them to request auto-connection here. This can create certain “disparity” between plugins installation and the user would feel that.
On systems without full confinement, printing will work fine (I.E systems without AppArmor support) - on Ubuntu/Debian/Arch(sometimes)/etc however, printing would break unless users have the cups snap installed. Eventually the plan for snapd would likely be 1) Ubuntu has this snap by default anyway and 2) the cups declaration alone would download CUPS, but for now, neither is the case.
The workaround in the documentation abuses a content interface to force CUPS to download. In the context of these other content interfaces, I think we can ignore the content aspect itself because what’s actually important to connect is the cups interface itself, and the content declaration is just a workaround to force the installation for people who don’t have it.
It should be zero cost for you to add (as in, you wouldn’t need approvals from the Store to do so), but in terms of reducing user friction or pre-empting future bug reports, I just thought I’d mention it since I was checking the rest.
Sorry for the delay in my response. If you think that the second option is not doable, we will need to go with the first one.
Context:
snap-declarations are created and maintained in the store side to define which connections/auto-connections are allowed for every snap.
Some content snaps, such as gtk-common-themes or gnome-46-2404, were granted global auto-connection to their slots. Any snap can auto-connect to these content slots by default.
Adding a content plug (such as gimp-plugins) to the snap-declaration makes snapd to ignore global auto-connections (as for gtk-common-themes or gnome-46-2404).
Thus, to enable gimp to auto-connect to gimp-plugins, without breaking other required auto-connections, we will need to keep the snap-declaration (store side) in sync with gimp requirements (snapcraft.yaml). It means that when you update the snapcraft.yaml to add/update content plugs (e.g. moving from gpu-2404 to gpu-2604) you will need to ask us to update the snap-declaration accordingly.
Hi. Since that’s how things are, all we can do is follow this procedure.
But what can we do now to ensure that the gimp-plugins interface is auto-connected without breaking the other content interfaces?
(We did not touched the snapcraft.yaml but even so the gimp-plugins auto-connection did not worked. How can we trust it will work in the future?)
