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:
gjs
gnome-characters
gnome-documents
gnome-maps
gnome-shell
gnome-sound-recorder
gnome-sushi
gnome-weather
gpaste
polari
seed-webkit2
Removing gnome-shell also means we have to remove gdm3, gnome-session, and
various GNOME Shell extensions and other GNOME-Shell-dependent packages
from s390x. Perhaps someone from Ubuntu can advise on which ones? I
tried using "dak rm -R -n" but the results quickly become unmanageable -
I assume we don't actually care about uninstallable GNOME Shell extensions
and other Architecture: all packages on s390x?
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?
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.
If distros' release teams want to rebuild dependent packages anyway, the
rule that could be used for that transition would be something along the
lines of this ben file:
Affected: .depends ~ "libgjs0g"
Good: !.depends ~ /\blibgjs0-libmozjs-/
Bad: .depends ~ "libgjs0-libmozjs-52-0"
After that transition has completed, the libgjs0-libmozjs-52-0 Provides
could be removed from libgjs0g. However, this is not critical-path and
does not block the migration of gjs.
See gjs' debian/changelog for earlier attempts to document this situation.
I hope this clarifies it.
Regards,
smcv
