[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#906016: transition: gjs built with mozjs60



On 05/10/2018 10:10, Simon McVittie wrote:
> Control: tags -1 - moreinfo
> 
> I think we're ready to upload gjs 1.54 to unstable for wider testing,
> and Ubuntu are already doing the same thing. This could cause some
> disruption in unstable, and will not migrate without removing some
> packages on s390x, but does not require a mass-rebuild of dependent
> packages: packages built against the old libgjs0g work fine with the
> new one, except in the cases where versioned Breaks were used.
> 
> The new mozjs version does not work on s390x, so to make gjs migrate,
> we will need to do architecture-specific removals (I'm not sure whether
> this should be from testing or unstable) of binaries from at least the
> following source packages:

Fair enough.

> gjs
> gnome-characters
> gnome-documents
> gnome-maps
> gnome-shell
> gnome-sound-recorder
> gnome-sushi
> gnome-weather
> gpaste
> polari
> seed-webkit2

> Is there a better way we can deal with packages like gdm3 (which require
> gnome-shell at runtime) than "Architecture: amd64 arm64 armel..." with
> a full list of all the architectures where mozjs60 is known to work?
> Perhaps a (slightly spurious) Build-Depends on gjs, to make sure they
> don't build uninstallable binary packages for s390x?

A build-dep would be preferred, either on gjs or gnome-shell or whatever you
deem appropriate.

> On Mon, 13 Aug 2018 at 10:38:58 +0100, Simon McVittie wrote:
>> libgjs.so.0 currently uses Spidermonkey 52 (mozjs52) and is packaged as
>> libgjs0g. The latest upstream version uses Spidermonkey 60 (mozjs60),
>> which I'm in the process of packaging. It isn't entirely clear to me
>> whether this will require a gjs SONAME bump
> 
> Because there have been queries about this:
> 
> My conclusion was that it *does not* require a SONAME bump, and dependent
> packages do not need to be rebuilt. I didn't rebuild GNOME Shell to test
> the new libgjs0g, and my desktop works fine.
> 
> libgjs0g 1.54.0-1 still has a Provides on libgjs0-libmozjs-52-0. This
> is counterintuitive, but intentional. It's there to avoid needing a
> transition in which every dependent package is rebuilt, which is not
> actually necessary any more.
> 
> Some background: in historical versions of gjs, the gjs-internals module
> exposed mozjs ABI as gjs ABI, and was used by at least GNOME Shell. As a
> result, the upstream developers should ideally have bumped the SONAME
> every time they upgraded to a new, incompatible version of mozjs;
> but because it wasn't, we worked around this with package names like
> libgjs0a, libgjs0b, ..., libgjs0g, and per-ABI virtual package names like
> libgjs0-libmozjs-38-0, with gjs' shlibs generating a dependency on both.
> 
> The gjs-internals module was removed by upstream commit d3e2f861 between
> versions 1.46.x and 1.47.0, in 2016. From that point on, libgjs can
> more or less be treated like an ordinary library: there are no longer
> any public symbols that expose mozjs ABI, and an application compiled
> against one version can run with any later version (as long as it does
> not make use of Mozilla-specific JavaScript syntaxes that has been
> removed from mozjs, but a rebuild wouldn't fix or even detect that,
> so versioned Breaks seem like a better tool to deal with it).
> 
> When we updated to gjs (>= 1.47) and libgjs0f/libgjs0g in 2017, nobody
> noticed that libgjs no longer has any public symbols that expose mozjs
> ABI, so we assumed that the virtual packages were still necessary.  As a
> result, the shlibs continued to generate a dependency on the virtual
> package libgjs0-libmozjs-52-0, and packages like gnome-shell and polari
> now depend on that virtual package. To avoid needing to rebuild dependent
> packages immediately and do a full transition, we continue to provide
> it from this version: the justification is that this new libgjs has the
> same ABI as the one that was built using mozjs52, even though it now
> uses mozjs60.
> 
> The new shlibs file does not generate a dependency on the virtual package,
> so we do not need a libgjs0-libmozjs-60-0 virtual package, and packages
> that have been rebuilt against gjs 1.54.x will simply have "Depends:
> libgjs0g (>= 1.54.0)" like any other shared library; the only relic of
> the package's unfortunate history is that the shared library package
> name is libgjs0g, not the expected libgjs0.

Sounds good.

My only question: is cjs moving to mozjs60 too, so that we can remove mozjs52?

Cheers,
Emilio


Reply to: