Snap accumulates content interface connections to multiple platform snaps

A strange case: kdenlive does not start and complains (on the console):

Cannot mix incompatible Qt library (5.15.3) with this library (5.15.2)

But how can that be? It uses the kde-neon extension, and its platform snap will surely not contain mixed Qt versions. Let’s check:

$ ls -al /snap/kdenlive/46/usr/lib/x86_64-linux-gnu/
lrwxrwxrwx 1 root root 27 Mai 25 13:50 /snap/kdenlive/46/usr/lib/x86_64-linux-gnu/ ->

$ ls -al /snap/kdenlive/46/kf5/usr/lib/x86_64-linux-gnu/
lrwxrwxrwx 1 root root 26 Dez  4  2020 /snap/kdenlive/46/kf5/usr/lib/x86_64-linux-gnu/ ->

Ok. It ships one 5.15.3 library that’s not included in the framework. But why does it see 5.15.2 libs? Does it declare the wrong framework plug?

The current version has:

$ grep "kde-framework" /snap/kdenlive/46/meta/snap.yaml 
    content: kde-frameworks-5-qt-5-15-3-core20-all
    default-provider: kde-frameworks-5-qt-5-15-3-core20

But the connections show something very interesting:

$ snap connections kdenlive
Interface                                       Plug                            Slot                                                                      Notes
audio-playback                                  kdenlive:audio-playback         :audio-playback                                                           -
audio-record                                    kdenlive:audio-record           :audio-record                                                             -
content[icon-themes]                            kdenlive:icon-themes            gtk-common-themes:icon-themes                                             -
content[kde-frameworks-5-qt-5-14-core18-all]    kdenlive:kde-frameworks-5-plug  kde-frameworks-5-qt-5-14-core18:kde-frameworks-5-qt-5-14-core18-slot      -
content[kde-frameworks-5-qt-5-15-3-core20-all]  kdenlive:kde-frameworks-5-plug  kde-frameworks-5-qt-5-15-3-core20:kde-frameworks-5-qt-5-15-3-core20-slot  -
content[kde-frameworks-5-qt-5-15-core20-all]    kdenlive:kde-frameworks-5-plug  kde-frameworks-5-qt-5-15-core20:kde-frameworks-5-qt-5-15-core20-slot      -
content[sound-themes]                           kdenlive:sound-themes           gtk-common-themes:sound-themes                                            -
dbus                                            -                               kdenlive:session-dbus-interface                                           -
desktop                                         kdenlive:desktop                :desktop                                                                  -
desktop-legacy                                  kdenlive:desktop-legacy         :desktop-legacy                                                           -
home                                            kdenlive:home                   :home                                                                     -
network                                         kdenlive:network                :network                                                                  -
network-bind                                    kdenlive:network-bind           :network-bind                                                             -
opengl                                          kdenlive:opengl                 :opengl                                                                   -
removable-media                                 kdenlive:removable-media        :removable-media                                                          -
system-observe                                  kdenlive:system-observe         :system-observe                                                           -
wayland                                         kdenlive:wayland                :wayland                                                                  -
x11                                             kdenlive:x11                    :x11                                                                      -

It has three (!) different framework snaps connected to its “kde-frameworks-5-plug”. So how can that be? Is it possible that those have been steadily accumulated while kdenlive updated its kde-frameworks-5-plug? Shouldn’t obsolete connections be removed if they don’t have matching content attributes?

Edit: @jriddel tells me those might be artefacts from switching between risk levels (e.g. candidate → stable), but isn’t that a supported use-case that shouldn’t break the snap?

I’m most likely missing something important, so please enlighten me. At the very least, the correct platform snap should be mounted as $SNAP/kf5. At the moment, an outdated platform snap gets mounted as $SNAP/kf5 and the current one will get $SNAP/kf5-2 (or an even higher number).

$ snap version
snap    2.53+21.10ubuntu1
snapd   2.53+21.10ubuntu1
series  16
ubuntu  21.10
kernel  5.13.0-20-generic

Can you run snap changes kdenlive and attach the output? If snap list --all lists more than one revision of kdenlive, can you check what is the default provider listed in /snap/kdenvlive/<other-rev>/meta/snap.yaml ?

$ snap changes kdenlive
ID    Status  Spawn               Ready               Summary
1546  Done    today at 10:59 CET  today at 11:00 CET  Refresh "kdenlive" snap
$ snap list --all | grep kdenlive
kdenlive                             21.08.2                       45     latest/stable     kde*              disabled
kdenlive                             21.08.3                       46     latest/stable     kde*              -
$ grep kde-framework /snap/kdenlive/45/meta/snap.yaml 
    content: kde-frameworks-5-qt-5-15-3-core20-all
    default-provider: kde-frameworks-5-qt-5-15-3-core20

I could reproduce this by first installing kdenlive from stable, and then refreshing it with edge channel. It looks like we have a problem when content interface changes (in this case kde-frameworks-5-plug: the default provider and content tag changed).

As a workaround, removing old frameworks (e.g. kde-frameworks-5-qt-5-14-core18) and leaving only the last one should fix it (but please let me know). This is of course not ideal so this will be investigated, thanks for reporting.

Yes. I have another snap (my own, freecad-ppd) that changed its base from core18 to core20, which triggered a change of the default provider (same extension though). It was also connected to two different framework snaps as a consequence on this machine.

That would work, but I still have other snaps depending on that framework. Removing the snap and reinstalling works, but that’s also nothing I’d recommend to new users without a second thought because it loses data in $SNAP_USER_COMMON.

Right, that doesn’t work if other snaps use the old framework snaps of course.

The gnome extensions avoid this by versioning the plug name itself, not just the content attribute, correct? That could be a simple solution in the short term for the kde-neon extension then.

Yes, that’s correct.

Alright then: