This isn't an urgent matter at all, I'm just posting for future discussion.
Is your feature request related to a problem? Please describe.
Problem: Distributing software for Linux platforms has always been painful compared to Windows and Mac. There are 2 conventional methods:
- The developers offers source code and the user has to build it.
This approach burdens the developers the least (in a sense) yet can cause the user much trouble. Missing libraries, outdated toolchains...you name it. Uninstalling and updating the software can also prove to be difficult.
- The developers offers the binary package and the user installs it via comands like
Users can still counter dependency issues but it should be much milder than the troubles from building the source. This method also allows incremental updates. This time the headache is the developers', as different Linux distributions use different packages, for example .deb packages cannot be installed on RPM-based distros and vice versa. Adding to the confusion, even distros using the same package formats might not be able to use the same package. RHEL and SUSE are both RPM-based but their RPMs are different, for instance. This method requires the developer to maintain the packages themselves -- they'll have to choose between either diverge significant effort to maintain packages for each Linux distro, or focus on a small range of distros and leave users of other platforms to build the software from source.
Describe the solution you'd like
Enter the concept of Universal Apps, where the developers bundle their code and dependencies in an sandboxed package and the user can safely run/installed these ready-to-run software without worrying if their OS might conflict with the software. I recently had a taste of Universal Apps as a user and I think these 2 solutions feel pretty nice: Flatpak and AppImage. A user can easily install a Flatpak software by first installing flatpak (like
sudo apt install flatpak) then running
flatpak install <software_source_repository> <software_name>, whereas AppImage software is simply one execuatble file that can be launched by
chmod +x <software_name>.Appimage (if the file doesn't have the execute permission) then
./<software_name>.Appimage. In both cases, the developer needs to maintain only 1 single binary package, period. Flatpak allows for incremental updates, and I think Appimage is starting to do so too.
Describe alternatives you've considered
Docker can definitely do the job -- OpenFPGA is already offering Docker images. But Docker might be overkill and still a bit complicated.
Snap is practically Canonical's counterpart of Flatpak, except Canonical completly controls the Snap platform much like how Apple controls App Store (we cannot distribute snap packages without uploading them to Snapcraft and have Canonical review our requests). In contrast, flatpaks can be hosted on our own repos.
There are a few potential setbacks of Universal Apps.
- Performance and size. Compared to conventional methods, Universal Apps tend to take more disk space, as they rely on bundled dependencies, instead of reusing what the OS already has. Universal Apps also seem to suffer from performance penalties, though I don't think either of these issues are of big concern for our GUI.
- Worth the effort? Building an Universal App isn't exactly a cakewalk, especially when all of us lack the experience and have other priorities. If FOEDAG ends up mostly being used by FPGA companies to be the foundation of their own software suite, then offering it as an end-user-oriented Universal App might not make much sense. Besides that, a sandboxed FOEDAG might have trouble interfacing with EDA backends, but my grasp of Universal Apps is too thin to be sure right now.