> > 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 https://github.com/electron/electron/issues/3797
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/issues/132#issuecomment-560019244
_______________________________________________
beast mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/beast
