FETCH for external packages is required
All major packaging systems disallow fetch during build for security reasons, rpm/debian/bsd
As I wrote under (1) above, you could prefetch the downloaded 3rd party sources, and combined with the beast sources + Electron could build Beast offline.
Beast now has a hard dependency on Electronjs
NodeJS is hard-banned by all major packaging systems because NodeJS leads to insecure packages and they just don't package such software.
First, NodeJS doesn't lead to insecure software per se. Blindly installing npm deps can have that effect, yes, but that's not what the Beast build does. (And realistically, the same can happen with other language environments also.)
Second, Beast doesn't even need the NodeJS portion of Electron, just a modern web engine to display the UI, which is why I wrote that Firefox could take on this part in the future also.
Third, this is not the place to start a generic argument against use of Electron. If you care, https://electronjs.org/apps lists hundreds of apps that are based on Electron. It may take distributors some time - or years - to figure how and why they want to package Electron apps, but it will happen eventually due to user demand.
You made several design decisions that prevent most users from ever seeing your software because you are asking them to compile it by hand instead of installing it via a package. Compilation by hand is too hard for most users.
You're right that compilation is too hard for users. We don't advocate that users should compile Beast to get it working. Instead, we provide a pre-built AppImage, that works on Ubuntu and Fedora systems. Distributors/packagers are welcomed to build Beast for platforms beyond that, and that process is actually quite easy, as GNU-Make will tell you what dependencies are missing and you could even inspect the CI Docker images to understand how the build works.
Regarding the basic design choices that you talk about, we originally based Beast on Gtk+ and I invested heavily into that toolkit. As a result, ten years ago we had Debs, Rpms and earlier even BSD packages. The foundation wasn't good enough to keep up with feature requests and UI development demands though.
Changing that has allowed to move Beast into new and more interesting directions, and that at a previously unimaginable pace. For now, the focus is on reaching feature completeness for a 1.0 version, and once that's achieved we can possibly dial back on one or two aspects to ease packaging and integration. For FreeBSD specifically, a proper desktop application webengine is required first - the need of which is also recognized by other FreeBSD users as demonstrated in electron/electron#3797
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.