Would it be possible to get an officially supported native Linux package for both x86_64 and ARM64? Running natively will improve performance by being able to use native and updated libraries, etc. and have relatively smaller package size.
So the best solution is to just create a native distro package.
But there are like 9000 distros out there and supporting them all takes too much effort
Thatās why you only make one for Debian. Debian and Ubuntu-based distros are widespread and have a massive user base, so I can put the chance of a Linux user using BSt running a Debian-based distro being 9 out of 10. Even bigger bonus is that we can easily convert .deb packages to other formats like .rpm for Fedora/Red Hat and .pkg.tar.zst for Arch Linux (btw) package manager.
Flatpak can also be considered but I heard itās a massive pain to develop with.
Not sure itās good idea.
Native Linux packaging is painfull for some devs, i know because iām also a packager :")
i.e you need specific dependencies for each Debian/Ubuntu version that you wanna build, and other painfull things.
For me, the current package for Linux is good enough, the update for each release also can be done seamlessly, so no issue for me :")
I solved my Wayland problem by just adding Electron Wayland arguments direct in the AppRun file. You can insert this after the āNUMBER_OF_ARGS=ā$#āā line (for reference, I use Bootstrap Studio extracted from the AppImage using the bootstrap-studio AUR package):
# Run on Wayland if currently using Wayland
# This is a pretty hacky way to add Wayland support to AppRun
if [ $XDG_SESSION_TYPE == 'wayland' ] ; then
args=(--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations "${args[@]}")
NUMBER_OF_ARGS=$((NUMBER_OF_ARGS + 2))
fi
Now, I can use touchscreen to scroll pretty much anywhere plus some slight but noticeable smoothness.
Native Linux packaging is painfull for some devs, i know because iām also a packager :")
I havenāt really done native packages other than for Arch Linux so I cannot say much about that. On Arch Linux, I can say that making a package is as simple as just specifying the dependencies and their minimum versions plus copying/installing stuff thanks to the PKGBUILD. Looking at the AppImage content and this being an Electron app. I reckon it would be on the easy side to package.
And even then, you only have to support one package format anyways since people can easily convert them into their own.
Producing a deb, snap or flatpack package wonāt work for Bootstrap Studio because not everyone receives the same updates. Users with standard licenses donāt update past the 1 year mark so our autoupdate backend needs to determine dynamically which version to deliver. Maybe itās possible to develop workarounds, but shipping a single AppImage is easier.
I reckon it would be awesome if Bootstrap Studio has a, heh, bootstrapping launcher that allows users to input their license, then it checks the latest version the license allows. The launcher then downloads the full app to the user (default) or system (with root/admin, can be asked by Linux PolKit/macOS Authenticate/Windows UAC) data directory below.
Windows: %LOCALAPPDATA%\Bootstrap Studio (%/LOCALAPPDATA%: C:\Users%USERNAME%\AppData\Local)
System data directories:
Linux/BSDs/macOS: /opt/bootstrap-studio
Windows: C:\Program Files\Bootstrap Studio (same directory where the launcher is installed, which should be just one binary file like the rest)
The launcher then opens the main Bootstrap Studio app, which also checks whether the license saved by the launcher is valid and so on. The launcher launches, checks for updates, and syncs user settings for that license. This is kinda how Jetbrains Toolbox works but with more responsibilities. (Fun fact: JetBrains IDEs have the same licensing method as Bootstrap Studio, with the last version before license expiry being available permanently to the customer.)
I believe that a launcher is way easier to package since itās literally just one binary and you can package it to every packaging and all three supported OSs, plus you donāt even need to package the Electron app other than building it to the supported OS and putting it available for download to the client. Also would allow account logins if you ever decide to use that for licensing instead of just a license code. Easier to remember than random strings of characters.