The Kde content snaps are still in work in progress. There is already 2 global autoconenct request by KDE content snaps, which are of 2 separate version. But, the problem is, with each new update, if there is a new release, then will not it be problematic for the snapcrafters to create and maintain snaps. Also, if we don’t align the KDE content snaps with the gnome one, it’ll be problematic to use other content snaps with it (eg: Webkitgtk, ffmpeg content snaps). The KDE neon extension will also need to be changed with every new release, else everything will have to be done manually by the package maintainer. @sgmoore isn’t there any way to make it like the Gnome one (Gnome SDK has libraries from gnome 3.38 to gnome 45).
Hi. I am certain the original maintainer of the kde content pack tried something to this affect but said there were weird bugs introduced with mixed libraries. However, that was sometime back and I am more than willing to re-visit the idea. Unfortunately, I will be on hiatus for a bit while I sort out finances to stay online. Sorry.
It’d also increase the linker search times I’d imagine. The Gnome snap only has 2 “environments” in it, GTK3.38 and GTK4 which loosely corresponds to Gnome42. I don’t think there’s Gnome 45 stuff in there, because I’m expecting that while GTK3 to GTK4 was a clear API break and applications wouldn’t get confused by 3 VS 4, they would get confused between the versions within GTK4 itself.
In contrast, I feel like I see KDE content snaps every week. If they were all put into one mega snap, I’d have assumed it would bloat up massively in size, compounding the linker slowdowns with even more SquashFS compression.
Obviously fundamentally it’s whatever is easiest for the maintainers, but I think there’s a few technical differences between the Gnome ecosystem and KDE’s ecosystem and their use of snaps that mean it’s not as simple as just copying the other.
2 Likes
@sgmoore @James-Carroll Thanks for letting me know more on the kde ecosystem. Though in case of Gnome, there are two things, every gnome update almost has support for 1/2 older version of Gtk. But, I guess that’s not the case for KDE. Also Gnome SDK regularly updates the GTK4 and Libadwaita to newer versions, with each new release. So, I guess that’s just the way for the eco system to work. But I think if that’s the case, we still can do something with the extension.
eg: Added part in the yaml, under extensions, subversion may be? That’ll have the KDE release version number like thing. And match the environment, plugs and sdks matching to that?
I’ve just checked, I know I’ve seen the libadwaita version change but I genuinely didn’t expect the GTK4 version to change.
But looking at the Github history, it actually does change so my previous post is partially mistaken to which I apologise.
Importantly though, it still only has a singular version of GTK3 and GTK4, although that version of GTK4 does update overtime, my assumption here would then have to be that GTK4 has API/ABI guarantees that GTK3 didn’t have, so an app could be upgraded from GTK4.X to GTK4.Y without needing to be rebuilt.
I’m unsure if KDE could provide the same guarantees with ABI/API there but trust that Scarlett would know best here. If the API/ABI could be guaranteed then in theory you could move closer to a Gnome model without inflating the size of the snap massively, but if not, then the many content snaps model would probably still be most appropriate.
What I personally think is missing is that content snaps need to be cleared up automatically if there’s no snaps consuming them, which would mean KDE could keep doing it the way they currently are without having individual PC’s end up with a load of KDE content snaps that aren’t fullfilling any purpose.
1 Like