Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #119532 > unrolled thread

Epoch for quickjs

Back to article view | Back to linux.debian.devel

Contents

  Epoch for quickjs Jérémy Lal <kapouer@melix.org> - 2025-11-10 14:20 +0100
    Re: Epoch for quickjs Simon Richter <sjr@debian.org> - 2025-11-10 15:10 +0100
      Re: Epoch for quickjs Jérémy Lal <kapouer@melix.org> - 2025-11-10 16:10 +0100
        Re: Epoch for quickjs Soren Stoutner <soren@debian.org> - 2025-11-13 20:30 +0100
          Re: Epoch for quickjs Soren Stoutner <soren@debian.org> - 2025-11-13 21:40 +0100
            Re: Epoch for quickjs Jérémy Lal <kapouer@melix.org> - 2025-11-13 21:40 +0100
        Re: Epoch for quickjs gregor herrmann <gregoa@debian.org> - 2025-11-13 23:10 +0100
          Re: Epoch for quickjs Jérémy Lal <kapouer@melix.org> - 2025-11-13 23:50 +0100
            Re: Epoch for quickjs gregor herrmann <gregoa@debian.org> - 2025-11-14 13:40 +0100
          Re: Epoch for quickjs Jérémy Lal <kapouer@melix.org> - 2025-11-13 23:50 +0100

#119532 — Epoch for quickjs

[Multipart message — attachments visible in raw view] — view raw

Hi,

After some discussion with its current maintainer, I helped upgrading the
package to quickjs-ng,
a more active fork of quickjs.
Most software using quickjs embeds the source code,
so the idea is to make more packages in debian statically linked to
libqjs.a instead,
and experiment with a shared library too, when possible.
In that situation, I think it makes sense to upgrade quickjs to quickjs-ng
in the current
package, instead of creating a second source package.

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 ?

Jérémy

[toc] | [next] | [standalone]

#119535

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?

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.

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.

    Simon

[toc] | [prev] | [next] | [standalone]

#119537

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#119572

[Multipart message — attachments visible in raw view] — view raw

On Monday, November 10, 2025 8:00:01 AM Mountain Standard Time Jérémy Lal 
wrote:
> 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...

My personal preference would be to create a new package, so that the source 
and binary package names clearly specify that this is quickjs-ng instead of 
the older quickjs.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#119573

[Multipart message — attachments visible in raw view] — view raw

On Thursday, November 13, 2025 1:27:57 PM Mountain Standard Time Jérémy Lal 
wrote:
> That would have been my initial approach, if not for the fact that the new
> package
> will have to wait weeks, if not months, before being processed.

As someone who has a number of packages waiting in NEW, I am well aware of the 
frustration that can sometimes entail.  However, in this case, I think it is 
worth the inconvenience.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#119575

[Multipart message — attachments visible in raw view] — view raw

Le jeu. 13 nov. 2025 à 21:32, Soren Stoutner <soren@debian.org> a écrit :

> On Thursday, November 13, 2025 1:27:57 PM Mountain Standard Time Jérémy
> Lal
> wrote:
> > That would have been my initial approach, if not for the fact that the
> new
> > package
> > will have to wait weeks, if not months, before being processed.
>
> As someone who has a number of packages waiting in NEW, I am well aware of
> the
> frustration that can sometimes entail.  However, in this case, I think it
> is
> worth the inconvenience.
>

(forgot to reply to the thread).
Yes, and rethinking about it, it has new binaries anyway.
Thank you for giving the motivation to do the right thing !
I'll do a new package.

Jérémy

[toc] | [prev] | [next] | [standalone]

#119578

[Multipart message — attachments visible in raw view] — view raw

On Mon, 10 Nov 2025 16:00:01 +0100, Jérémy Lal wrote:

>Le lun. 10 nov. 2025 à 15:06, Simon Richter <sjr@debian.org> a écrit :
>> 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...

Does this mean that the new package will break all its reverse 
dependencies?


Cheers,
gregor

-- 
  .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
  : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
  `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
    `-   

[toc] | [prev] | [next] | [standalone]

#119580

[Multipart message — attachments visible in raw view] — view raw

Le jeu. 13 nov. 2025 à 23:41, Jérémy Lal <kapouer@melix.org> a écrit :

>
>
> Le jeu. 13 nov. 2025 à 23:05, gregor herrmann <gregoa@debian.org> a
> écrit :
>
>> On Mon, 10 Nov 2025 16:00:01 +0100, Jérémy Lal wrote:
>>
>> >Le lun. 10 nov. 2025 à 15:06, Simon Richter <sjr@debian.org> a écrit :
>> >> 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...
>>
>> Does this mean that the new package will break all its reverse
>> dependencies?
>
>
> Yes it will ! However, if you re-read the thread, you'll find why it
> doesn't matter:
> *The old package is only used by edbrowse*
>
>

Also Soren just convinced me to make a new package, so that point is n/a
anyway.

>
>>
>> Cheers,
>> gregor
>>
>> --
>>   .''`.  https://info.comodo.priv.at -- Debian Developer
>> https://www.debian.org
>>   : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801
>> 8649 AA06
>>   `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation
>> Europe
>>     `-
>>
>

[toc] | [prev] | [next] | [standalone]

#119592

[Multipart message — attachments visible in raw view] — view raw

On Thu, 13 Nov 2025 23:42:02 +0100, Jérémy Lal wrote:

>>> Does this mean that the new package will break all its reverse
>>> dependencies?
>>
>> Yes it will ! However, if you re-read the thread, you'll find why it
>> doesn't matter:
>> *The old package is only used by edbrowse*
>>
>Also Soren just convinced me to make a new package, so that point is n/a
>anyway.

Excellent, thanks for clearing up my confusion.


Cheers,
gregor

-- 
  .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
  : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
  `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
    `-   

[toc] | [prev] | [next] | [standalone]

#119581

[Multipart message — attachments visible in raw view] — view raw

Le jeu. 13 nov. 2025 à 23:05, gregor herrmann <gregoa@debian.org> a écrit :

> On Mon, 10 Nov 2025 16:00:01 +0100, Jérémy Lal wrote:
>
> >Le lun. 10 nov. 2025 à 15:06, Simon Richter <sjr@debian.org> a écrit :
> >> 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...
>
> Does this mean that the new package will break all its reverse
> dependencies?


Yes it will ! However, if you re-read the thread, you'll find why it
doesn't matter:
*The old package is only used by edbrowse*


>
>
> Cheers,
> gregor
>
> --
>   .''`.  https://info.comodo.priv.at -- Debian Developer
> https://www.debian.org
>   : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649
> AA06
>   `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation
> Europe
>     `-
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web