Le lun. 10 nov. 2025 à 15:06, Simon Richter <[email protected]> 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
