Open ubruhin opened 11 months ago
AppImages/Flatpack/Snap seem like the wrong distribution model. Is there a reason to avoid making distro packages?
AppImages/Flatpack/Snap seem like the wrong distribution model.
Why? How is it related to Wayland? Our problem with Wayland is Wayland itself and/or it's interaction with Qt, not the distribution packages.
Is there a reason to avoid making distro packages?
Because it's 100 times more effort to build for example a *.deb, and then you covered only a few distributions and are still not in the official repositories. I have no time for such an inefficient packaging workflow. But of course I'd love to see some package maintainer building and distributing native distro packages (which actually do exist for several distros, e.g. NixOS). There's nothing which prevents people from doing this.
With AppImage/Snap/Flatpak we can provide packages for basically any Linux distro in relatively short time, typically updates are deployed to users within a few hours after we create a new LibrePCB release. But that's all offtopic here, if there's an interest in discussing this I'd prefer opening a forum thread.
Distro packages are better but they're pretty labor intensive and there are simply too many distros to support. It's cool if someone is willing to maintain a few distro-specific packages, but I think there should always be a universal option.
AppImages, Snaps and Flatpaks add an extra abstraction layer and you often need to install tons of external deps, which is not ideal, and I guess it's the main reason why some people don't like those options.
The best option IMO is providing an universal Linux binary. I'm not deeply familiar with the low level stuff, but I guess it can be achieved with static linking or switching to musl. I think Bitcoin Core is actually QT-based and they do provide universal binaries, so it's certainly not impossible.
I can take the effort for *.deb packaging (Ubuntu, Mint, Raspbian ...), I have own server with a lot virtuals/ build system so i can deploy (not test) binaries for any free system running x86 or raspberry ARM. It should not take much time, the project is well organized, it is only one more CI run per architecture and little edits on CMakeLists needed to generate correct package with all translations. Only effort will take discussion of deployment (my server is not on public IP due to security concerns so it can't be connected with GitHub directly)
The standalone build is not so easy as you say, it is a LOT of work, because the full Qt library should be recompiled by own and all of the build dependencies should be changed.
BUT: If there is as much problems with wayland as I can read here, the deb package will be unusable for users, when they use wayland. This issue should be fixed (or checked) first. So I am investigating how to load wayland over plain x11 now :-)
Please please open a separate thread for discussing distro packaging - it is offtopic here :wink:
BUT: If there is as much problems with wayland as I can read here, the deb package will be unusable for users, when they use wayland. This issue should be fixed (or checked) first.
Exactly! Wayland issues are not related to packaging at all.
My appologies, I had taken, "In the AppImage, the Wayland Qt plugin is not shipped" to mean packing was an issue.
About fixing Wayland, whenever there are inexplicable bugs in a project, my very first approach is to ensure that everything explicitly deleted is always immediately set to nullptr
. This is a surefire way to identify 99% of memory issues. I recently fixed https://github.com/Robotips/uConfig which had mysterious issues but a commit two years ago swapped two lines and it had been running using deleted memory until a few weeks ago.
I'm not saying this is the issue but if the behavior is inexplicable then it very well could be.
SUMMARY
Currently in our official AppImage, Flatpak and Snap package we explicitly disable Wayland due to several issues, forcing LibrePCB to be run with XWyaland instead of natively. However, for long term we should fix the issues and enable native Wayland support in those packages.
Generally LibrePCB does run on Wayland, which is the case when compiling LibrePCB from source. However, I observed several issues:
Maybe there are more issues, so we need to do some additional testing on Wayland to find them.
SOLUTION