or am I just expecting things too fast?
No, just looking in the wrong ppa: try
However: unless using the latest 'buntu the best you get is 2.9.9 or less
edit:
Ahh⌠I see it is there but still on Gimp 2.10.0-RC2 and only for 'buntu 18.04 / 17.10
Still using Xenial? Then the best so far is Gimp 2.9.9 Needs some major package updates to get 2.10 to work.
Sure using Xenial. Itâs a LTS version and because I need my machine to perform and run, I wonât upgrade anytime soon - LTS versions have to wait for 18.04.1 to activate dist-upgrade. No 2.10 for the biggest group of Linux users before July?
You can use the AppImage provided by @Carmelo_DrRaw that is linked here, or you can install flatpak and install the version from flathub.
Iâd bet there is a snap of it too.
I admit that I have never cared for flatpak or snaps - whatâs wrong with ppas, repos and good old dpkg (apt)?
Cross-compatibility?
I guess it becomes more and more difficult to maintain a recent software in an old ecosystem since you will have to provide more and more libraries in newer versions the software relies on in the ppa. And these have to be compatible to the rest of the ecosystem, i.e. they should not break something else. With the appimages etc., you have to provide the new libraries as well, but you do not have to care about compatibility to the rest of the ecosystem. If you can build it on your system, you can just ship the libraries that are used at build time.
Disclaimer: Hope this makes sense, ant itâs not over-simplified. I am not a programmer.
5 Likes
For me, it makes perfect sense, and perfectly summarises why PPAs are a source of troubles.
Actually, a native install should still be the preferred way. I consider these new bundles as a last resort for people who canât get real packages for some reasons. Reason being that the stupid sandboxing of applications breaks all kind of things. For example, you canât use darktable from within GIMP.
Why? At least in the AppImage case, there is a well-established âworkaroundâ to allow the invocation of external programs from within the AppImage itself. This workaround involves keeping a copy of the original system environment, and restoring such environment when invoking external programs.
This is achieved by loading (via LD_PRELOAD) a patched version of the execv* class of functions, so that no modifications are needed to the application sources.
In other words, if my GIMP AppImages are not able to invoke Darktable for RAW processing, than thatâs a bug that we need to investigate. Normally, it should just work.
Notice that in such scenario, the Darktable executable could also be another AppImage package, it will still work when invoked from GIMPâŚ
It does on Debian stable with a self-build darktable install. Building Gimp on Debian 9 got to difficult for me. I donât want to talk about GâMIC 2.0. I was very sceptical about this Appimages, but they are easy to handle for end users.
1 Like
Thatâs the problem. There are AppImage/flatpak for the main app, but we donât know which compiled plugins also require to be AppImage/flatpaks and I have not heard of any provided in that form. We will have the curate a list of 2.10 plugins that can be used nativelyâŚ
In any case this is a real step backwards from apt install gimp-registry.
We need to curate a list, period. Gimp registry is a mess! We are trying with the pixls.us gimp-scripts repo at github!
1 Like