Native Linux application packaging

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.

But why not use the AppImage provided?
Earlier, I have submitted a bug report about not having Wayland support, and received the response that the Electron should be able to do so but the flags are not being passed. I reckon this is the result of probably missing libraries, which caused by the AppImage developer who would rather die than support Wayland.
PR: Add support for the wayland platform by buresu · Pull Request #540 · probonopd/linuxdeployqt · GitHub
Boycott Wayland: Boycott Wayland. It breaks everything! · GitHub

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 :")

1 Like

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.

Happy to hear you’ve solved the wayland issue!

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.

2 Likes

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.

  • User data directories
    • Linux/BSDs: $XDG_DATA_HOME ($XDG_DATA_HOME: ~/.local/share)
    • macOS: ~/Library/Application Support/BootstrapStudio
    • 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.