Snaps have content plug which is used as a medium to create a shareable library for many snaps. But, snaps will need those dependencies while building too. That’s where sdk snaps came up. Now, let’s take a scenario with the qt sdk snap,
A snap that’s build with qt 6. Now, the runtime content snap got an update with the new release of 6.1. Which means the sdk has also been updated. But, how can one guarantee, that the snap has been rebuild with qt 6.1. It’s never in the hand of the snap maintainers or developers, to guarantee the api compatibility. And thus, whenever the runtime update hits the user, the users face seg faults or errors of api mismatch. Now, one snap, that’s the qt runtime snap is installed. It can’t have the 6 and 6.1 version always active at the same time. Neither we can always come up with a new snap with each new point release. Neither we can even specify the channel in the default-provider part of the content plug of the consumer snap. We do have tracks, but as said before, we can’t have both 6 and 6.1 track of the qt runtime snap installed at the same time. Now, this issue is with all the sdks that are currently available, and apps that depends on shared objects for the libraries. And this is also problematic for libraries like ffmpeg or qt, where backward compatibility is very less.
Proposals
Allow 1 snap have multiple tracks installed and active at the same time and make the track creation
Create another way where we can easily guarantee the abi and api compatibility.
Completely separate way have shared dependencies
Current Scenarios
Currently, from my knowledge, the only content snap that was available sometimes ago was the gnome content snap. And gnome one doesn’t face such issues much, simply because, most of the gnome and related libraries are backward compatible which is not true for the rest of the libraries.
Can we have a better solution to this problem? This recently created a mess with the kde snaps, where almost all the snaps broke, as they weren’t rebuild. What are best practices that are suggested?
Don’t feel bad, I have been busy breaking KDE snaps all morning with a new QT release. I thought I could keep things in a smooth transition with updates qt → kf6 → apps. It went fine until apps, the process is very slow and manual and takes to much time, not to mention launchpad is very grumpy with all the work. Our solution in qt5 was to have a new snap for every release and it was versioned, but this takes up enormous amounts of space for users with a content pack for every snap… and not a solution I want to go back to. I am interested in ideas.
The snapd team has recently been discussing auto-removal of unused content snaps and base snaps. However, there is no formal specification or timeline.
Content snaps that break API compatibility or use a different base should be discrete snaps.
This adds maintenance overhead. This requires snap name requests, auto-connection requests, and increases debugging (e.g. “why is this bug occurring in ffmpeg-6-core22 but not ffmpeg-6-core24?”)
Rather than supporting a full matrix of versions and bases, content snaps should not be created for newer versions on older bases
There could be a mismatch if a snap or content snap is manually refreshed or interrupted during a refresh.
KDE snaps could add a script to their command-chains to check if the qt and/or kde content snaps are compatible and suggest users to refresh the content snaps
A concept similar to epochs could be implemented in snapd for defining ranges of compatibility between snaps and content snaps
This idea would need to be refined and specified with the snapd team
The QT SDK snap is not reliable for backward compatibility. In some cases, a rebuild of the same source is not compatible.
The build of this snap could be brought into Canonical to make builds more consistent.
An API checker could run on the shared objects to ensure compatibility.
I don’t know how to take this. I am consistent in with we have to be in line with KDE neon as the dependencies are updated in their repos to match what we need for our applications. We are still on core22. When they update, I update. Perhaps Canonical can take on a standalone QT for non KDE snaps to use.
I like the command-chain script idea. I also need to sort out a reasonable rebuild the $world when we release a new version of qt6/kf6.
