Update to org.gnome.Platform runtime version 41
akurtakov opened this issue · 14 comments
Hello...
wdym: Runtimes and SDKs (for the all plugins too) ?
Fábio
There was a patch proposing this in #124. We welcome it to be revived based on current manifest contents. 🙂
btw while we are at it, I propose that we don't change the "version/branch" for plugin for Gimp 3 and keep it to "3" even if we update the runtime. Can always trigger a rebuild. It's probably easier.
(and maybe try the same for 2.10)
btw while we are at it, I propose that we don't change the "version/branch" for plugin for Gimp 3 and keep it to "3" even if we update the runtime.
Not sure I understand what you are proposing. Do you mean the "branch": "stable" metadata? The "version": "2-40" in "org.gimp.GIMP.Plugin"?
Could you write an example?
Also explain what it changes, why we do as we do right now, and what it means to change to do as you propose? Just to understand what is what, no opposition from me by the way. 🙂
In beta (2.99) plugis are branch/version 3. Unlike on stable were this as an indication of the runtime version: 2-40, that we changed when runtime got bumped, making it necessary to update the plugins (creating a new branch). While it's safer, I'm not sure it is necessary, and it would make bumping the runtime easier, I think.
While it's safer, I'm not sure it is necessary, and it would make bumping the runtime easier, I think.
I see. The problem I see is that I don't think that the runtime version really gives API/ABI information. As far as we know, a higher runtime version could contain the same version of a lib, or a higher API/ABI-compatible version, or a higher version which would break binary compatibility. And probably it does a mix of this, but we simply don't have this information from the runtime version, right? It's not correlated.
This being said, it looks like you were right by staying on the safe side with the GIMP_API-RUNTIME scheme.
Now I'm pretty sure not bumping the plug-in version when bumping runtime would be fine most of the time. Then we'd simply have to react when we discover a problem afterwards (i.e. when someone reports a bug).
More annoying cases are the subtle ABI-breaks, which may not be easily discoverable immediately as plug-ins may look like they run fine, except they are bugged. For these especially, I am tempted to want to keep your current naming scheme, because such bugs can be real diagnosis nightmares.
What do you think?
@Jehan the reason why runtime version is important is that this is about the ABI that the plugin expects. If you try to use plugin built against older runtime with app running on newer runtime, it might not load at all. Runtime with same version has ABI backwards compatibility guarantee. New version will most likely have breaks. (that said, most dangerous bumps are probably when the backing freedesktop-sdk runtime changes as well since gnome runtime is based on that)
I know all of this, but changing the plugin version is a PITA. flatpak doesn't handle the case, GNOME software doesn't handle the case.
By handle the case, it is "plugin version changed on upgrade, let's upgrade all the extension packages that match as well". Instead the user has to figure it out. At least for GIMP plugins they only extend GIMP. Unlike audio plugins.
And it's a lot more work. And I still don't even have the permissions to change the default branch on the plugins I maintain (it's an annoying detail).
It would probably be easier if the plugins had smaller ABI surface than an entire runtime.
well, it is libgimp, but then there is gtk.
Just tested the build from #128 and GMIC fails with:
/app/extensions/plug-ins/gmic_gimp_qt: error while loading shared libraries: libicui18n.so.67: cannot open shared object file: No such file or directory
Right, ICU is among the libraries that typically get updated with Fall runtime releases but not with Spring. What you could do is ship these missing libraries but not their development files with app to facilitate gradually rebuilding everything.
To be fair I'm not surprised. It just validated my plan to coordinate the release. GMIC is a bit of an odd one as I do have to build Qt5. It's a fragile situation but the number of GIMP plugins is relatively low.
I have addressed build changes with flathub/org.gimp.GIMP.Plugin.GMic#20