Le lun. 10 nov. 2025 à 15:06, Simon Richter <
sjr@debian.org> a écrit :
Hi,
On 11/10/25 22:15, Jérémy Lal wrote:
> However, upstream quickjs-ng version is 0.11.0, but current quickjs
> debian version is 2025.04.26-1.
> Policy 5.6.12 requires to ask here the question:
> is it okay to use an epoch 1:0.11.0-1 in that case ?
Are you replacing the main package, or are you providing an alternate
package (quickjs-ng) that generates a transitional package, and no
further versions of the old package will be uploaded?
Replacing the main package.
The old package is only used by edbrowse (reverse build-dep on libquickjs),
and we are already working on it (upstream update added support for quickjs-ng).
In the latter case, it is also possible to give that transitional
package a version number like "2025.99+really0.11.0" -- a source package
can build binaries with different version numbers.
Yes, good idea. And that should also work with upgrading quickjs "in-place".
The other question is whether this is a drop-in replacement, or if it
should really be named "quickjs-ng", and dependencies adjusted, with no
transition managed through packages.
It's not a drop-in replacement, though there are more and more packages switching to quickjs-ng.
Porting can be easy in the simplest cases...
These packages embed "quickjs":
Easy to upgrade:
hugo (runs only the executable, easy to update)
edbrowse (with an existing upgrade to quickjs-ng)
node-quickjs-emscripten (upgradable to quickjs-ng compatible version)
Unknown:
elinks
giac
Not easy to upgrade:
pdf.js (it's used as a wasm blob to run sandboxed scripts, doable with quickjs-emscripten, but maybe not trivial at all)
libjavascript-quickjs-perl (not easy)
pljs (not easy)
and these packages embed (or support) "quickjs-ng":
warzone2100
r-cran-quickjsr
radare2
libnginx-mod-js
qbs
Jérémy