Keeping the sdks at par with the runtime snaps

snap
3

Discussion points on this from the 2024-Aug-02 Starcraft Clinic:

  1. The snapd team has recently been discussing auto-removal of unused content snaps and base snaps. However, there is no formal specification or timeline.
  2. 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
  3. 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
  4. 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.
1 Like