Autoconnect ksnip to kde-frameworks-5-core18

aah, ok, thanks for updating :slight_smile:

I +1 auto connection.

@sergiusens thanks for the support.

Today is a week since I posted the request, we have 2x 1+, is the request now granted? Whats the process from here on?

I think it just needs intervention from someone like @roadmr


Per Process for aliases, auto-connections and tracks the usual waiting period is 7 days (it might be somewhat longer due to queue length - sorry about that), meaning someone should get to it soon.

  • Daniel

Please hold on. kde-frameworks-5-core18 is owned by another publisher (the KDE project) and that publisher has not requested auto-connection for the world and unlike the gnome content snaps, there is no statement from them stating their pledge to not break consumers (this is completely within their right-- it is their content snap to be used by their snaps).

@roadmr - the point of content snaps is to have them auto-connect from the same publisher, not arbitrary publishers. For arbitrary publishers, we either need a global auto-connect or both sides need to acknowledge the risk (which is not good for users if both sides say “sure, I’m fine to break/break you”).

For all the same reasons as discussed in lyricfier, I vote -1 to auto-connect this interface. ksnip could easily break at anytime since the kde team has not declared to not break consumers and the store granting this would be inappropriate since that would be the reviewers vouching on the store’s behalf that ksnip won’t break. As reviewers, we can’t make that guarantee and it would be unfair of us to place that burden on the kde team or ksnip’s users.

If the kde team wants to seek a global auto-connection, that should be done elsewhere. Otherwise, ksnip should probably instead use kde-frameworks-5-core18 as a build snap or fork it. In this manner, the ksnip publisher can release on their own cadence and QA and not risk breaking its users.

@jriddell - can you comment on your intent to seek global auto-connect for the kde-frameworks snaps?

@reviewers - please note, auto-connecting the content interface between arbitrary publishers is not typically allowed. Please see Process for aliases, auto-connections and tracks (“auto-connection request considerations”). For those that have voted in the affirmative, please justify why you feel this request is unique and should be auto-connected.

@jdstrand Kind of sad to hear that. I’m not involved in the snap philosophy so can’t argue with you but for me your comments mean stopping snap support for my application. I haven’t released stable yet and I’m already getting issues from users complaining about the snap not working and there are probably some of them who already abandoned my application as the first contact with it was an error message about missing dependencies. In it’s current state, it’s just bad user experience.

Is the alternative in a case like this to add the kde-framework snap to stage-snaps?

Note: I talked to @jriddell on Matrix and he said he’ll request auto-connection for the kde-frameworks-5-core18 snap tomorrow, so that should solve the issue of ksnip and every other snap using this content snap.


@galgalesh thanks. I hope this works out and resolves our issue.

Note, that the kde publisher is going to request a global auto-connect so this request will be unneeded when it is granted.

That said, I may have not been clear. If you plug another publisher’s content snap, they are under no obligation to not break your snap by changing ABI, etc, so the default policy protects you and your users. You as the ksnip publisher are under no obligation to plugs another publisher’s content snap so you are free to do what is needed, including forking the other publisher’s content snap or using it as a stage-snap. In that manner, you can control updates to your forked content snap or your snap that uses a stage-snap and not break your users if they happen to get a breaking update to the other publisher’s snap. This provides a robust user experience as opposed to a potentially unreliable one.

Again, it sounds like the kde publisher (the one that publishes the kde-frameworks-5-core18 snap) is going to pursue a global auto-connection which will include them stating they will not break consumers like ksnip, which will allow you to trust that your snap won’t arbitrarily break.

You are correct - sorry. I’ll change my vote to +0 then (i.e. “that’s not the way to do it, sorry”). I did miss the fact that cross-publisher autoconnects are not usual and that it depends heavily on the provider guaranteeing a stable “interface”.

  • Daniel

@jdstrand, Note that these people are not using the kde-frameworks-5-core18 snap directly, but this simply gets pulled in because they use the kde-neon extension. This adds to their confusion and frustration.

Although I agree with @damir that this situation is very confusing, I have tried to warn publishers from using the kde-neon extension by putting the following notice on top of the kde-neon extension documentation:

:warning: This extension is currently only available for the KDE project itself. Snaps from non-KDE publishers will not get automatically connected to the KDE runtime snap required by this extension.

I understand and respect the decision to only auto-connect content snaps when the author of the content snap agrees to that. Otherwise, we would end up with a bunch of snaps suddenly breaking because a content snap breaks binary compatibility.

However, I think this issue could have been handled better by the Snapcraft team. It is very confusing for publishers that an official Snapcraft extension can only be used by a single publisher, especially since the gnome extension is intended to be used by everyone. I asked about the plans for the Gnome and Neon extensions back in Oktober and nobody raised the issue that the Neon extension was only going to work for the KDE Neon project. So I wrote documentation on how to use the Neon extension, which was even mentioned in an Ubuntu blogpost, but even the Ubuntu blogpost did not have a clear warning that this extension would not work for snaps published by other people.

So I was very surprised that when I contacted the Snapcraft developers about the content snap not being auto-connected, they told me that this was not a mistake, that this was deliberate…


So, to summarise, which is the correct or “preferred” way to build a qt snap?
Add the kde snap in stage-snaps?
Use the version of qt in bionic via the desktop-qt5 part?

There is also the kde guide:
that basically shows something very similar to the kde-neon extension, just not automated

This is my own opinion:

Currently, I think you get the best end-user experience by using the desktop-qt5 part. This is a tutorial for how to do that: [Deprecated] Desktop App support - Qt5. If you’re targetting default Ubuntu, this option also has the best desktop integration; it changes the KDE theme to look like the Gnome theme.

After kde-frameworks-5-core18 has a global auto-connection, the KDE-neon extension will be a comparable option with some advantages and some drawbacks. This is a tutorial for the extension: The kde-neon extension

Advantages of kde-neon extension

  • easier for the people creating the snap
  • also includes KDE frameworks, not only Qt itself
  • has smaller snap sizes and more KDE/qt-specific fixes.

Disadvantages of kde-neon extension

  • less integration with the Gnome desktop; these apps use the default KDE theme when they run on a Gnome desktop.

The content snap from the KDE guide will not work for the same reason as the kde-neon extension. Imo, that guide is inferior to the kde-neon extension in every way; the extension basically does everything the guide tells you to do, but the extension does it better.


@sergiusens and @cjp256 - while it sounds like the kde publisher is going to request a global auto-connection for the kde frameworks content snaps, assuming that is voted in the affirmative, are there other official extensions that are only used by a single publisher? If so, can something be done to make this a better developer experience?


Well, the publisher is going to request auto-connection… it was planned about a month ago, maybe just delayed to all the things going bonkers in the world we live in :wink:

Connecting interfaces between snaps of different publishers should however be an agreement between publishers, I believe this is what we agreed to so many moons ago. So what is the constraint or problem if the publisher is willing to commit stability for the snap of a different publisher but not want to for all publishers?

This is hypothetical as I noted that this publisher in particular was seeking auto-connect for this particular snap.