On Fri, Feb 18, 2022 at 2:30 PM Fabio Valentini decathorpe@gmail.com wrote:
On Fri, Feb 18, 2022 at 1:36 PM IƱaki Ucar iucar@fedoraproject.org wrote:
Hi,
The new version of RStudio [1] now bundles quarto [2], a publishing system written in JavaScript and TypeScript that in turn bundles Deno [3] (runtime written in Rust) and its standard library (this is not binary, but it's tagged independently of Deno at the moment), deno_dom, and Dart Sass (other binary dependencies are pandoc and esbuild, but they are part of Fedora already).
I'm a bit overwhelmed by this. Does anyone see any sane way forward here? Anyone willing to help? Some thoughts:
- We could package Deno, but how stable it is, and thus how important
the tie to a specific version might be. Also, there's the question about how to handle its standard library and third-party modules. Maybe we could follow the same strategy as with nodejs, allowing bundling specific versions.
I have tried packaging deno as RPMs. It is possible, but quite a big task.
The packages are now a bit out-of-date because I didn't have time to update them lately, but here's the work-in-progress .spec files for everything needed by deno: https://github.com/ironthree/deno-rpms and here's the work-in-progress RPM packages: https://copr.fedorainfracloud.org/coprs/decathorpe/deno/monitor/
The "deno" binary does work, but the packages would need working with upstream to fix some (mostly licensing) issues before they could be submitted as Fedora packages. (Note that building deno with vendored Rust dependencies would not really help, since those aforementioned issues would also need to be resolved in that case.)
Oh, and I forgot to mention: deno only supports building / running on x86_64 and aarch64. So if you need deno for anything, be aware that it's only available on those two architectures.
Fabio