tauri
tauri copied to clipboard
tauri-apps
[feat] Solutions to support different version of webkit2gtk on Linux
Describe the problem
As Ubuntu 22.04 coming, former versions will stuck into webkit2gtk 2.34 forever. This mean distros version like this won't get the header support of custom protocol from 2.36 and future possible features like webrtc. For wry, it could just add a feature flag or a few checks. For tauri, I believe this will cause users headache. They definitely want to just get a feature and work for all their customers.
Describe the solution you'd like
@FabianLars has an idea that force users to build on the latest systems possible with something like cross. But it will probably wait after 1.0
Alternatives considered
Another solution could be flatpak. But it could require more efforts.
Additional context
No response
To clarify, this only affects developers (tauri users) and not end users, is that correct?
My 2c: It's a small ask to have devs to upgrade their systems frequently. It's a big ask to force end users to upgrade, especially if they're on some LTS version that is still alive and well.
To clarify, this only affects developers (tauri users) and not end users, is that correct?
Well kinda both. Excuse my wording, but linux is really fucked up. The problem is that if your app is built on a newer system (namingly the (g)libc version) it won't work on older systems.
So, support for older end user systems and support for newer webkit versions are more or less mutually exclusive
Edit: Talking about .deb and .appimage and similar distribution methods. Flatpaks (via flathub) don't/shouldn't have the same problems, but it's way way harder to create&distribute for non-linux devs...
On a different note, ubuntu 20.04 did get 2.36 against my expectations. But well, doesn't matter too much i guess.
Shit. Seems like we're drifting into tradeoff territory.
The problem is that if your app is built on a newer system (namingly the (g)libc version) it won't work on older systems.
...If you also target a newer version of webkit? Or is this statement true independent of that?
What's attractive about the new webkit versions?
Or is this statement true independent of that?
Doesn't matter. If it works or not solely depends on the glibc version (which is somewhat bound to the system version). Also you can't just target a newer version of webkitgtk than your system has.
What's attractive about the new webkitgtk versions?
2.36 added header support for custom uri schemes which we need to "fix" our IPC bottleneck. 2.38 will, if all goes well, add webrtc support (no idea what else may be added)
As main home and work Linux user I see one simple solution, You should support only new version Linux and max 1 generation to back. So for example for Ubuntu if current the new version is Ubuntu 22.04 Official support should be only for 20.04 and 22.04. I don't see sens to lost necessary resources for solving bug in 18.04. This is this same like Windows 8, 7 etc. You don't support this version.
@Apogeum12 Unfortunately this is not something we can or want to do. Only if we absolutely have to. If we ignore that we already get enough complains for not supporting dinosaur distro X, this wouldn't solve the problem for the next webkitgtk version which probably won't land in 20.04.
This is this same like Windows 8, 7 etc. You don't support this version.
We do support Windows 7 and up.
We do support Windows 7 and up.
@FabianLars I didn't know that, but Windows have backward support by years and this is one of reason why is like elephant from one side and so good from other. And also you must remember then windows or OSX is supported by companies with a thousand developers with great support for end user, then Linux isn't.
Unfortunately this is not something we can or want to do. Only if we absolutely have to. If we ignore that we already get enough complains for not supporting dinosaur distro X, this wouldn't solve the problem for the > next webkitgtk version which probably won't land in 20.04.
People always will be to complain. The question is what you prefer, good clean, stable and with the new features in environment on Linux or old with so dinosaur baggage for happy ten people. Old kernel or distribution usually uses on the server. I don't see any sense uses 16.04, 18.04 or even 20.04 in a 1-1.5 year for now, to use by end user with building desktop application for such version systems. But this is only my opinion and experience with 5 years when I use only Linux desktop like in work and in home.
Having done a fair bit of research, there's a few ways:
- For Flatpak there should be no problem. We can target the latest Gnome runtime and older systems can run this just fine.
- For AppImage it's possible to build on a newer system and include (g)libc, the linker and such for compatibility with older systems. However it requires rewriting the entire AppImage bundler from scratch to use
appimage-builder. As well as requiring Docker to build AppImages locally.
I think Flatpak should be the preferred solution here. With an AppImages rewrite as a nice to have.
Closing this as we'll focus flatpak option. Let's keep the discussion in #4426