Bug#916347: epiphany-browser: Don't include in Buster

[Simon McVittie]

On Fri, 14 Dec 2018 at 10:17:18 -0600, mcatanzaro at gnome.org wrote:
> On Fri, Dec 14, 2018 at 10:02 AM, Alberto Garcia <berto at igalia.com> wrote:
> > Notice however that the latest stable release of WebKitGTK+ is always
> > available in stable-backports at the same time as in testing, so it
> > is indeed possible to run Epiphany from Debian stable with the most
> > up-to-date WebKitGTK+.
> 
> Perhaps the epiphany package could be made available only in backports?

This only works as long as the epiphany package is in testing, because the
backports team are unwilling to have packages that are in backports but
not in testing (they enforce this so that there is an upgrade path from
Debian 9 with backports to Debian 10, and from Debian 10 with backports
to Debian 11, and so on).

However, if it isn't going to be in the next stable Debian release, then
it needs to be kicked out of testing at some point, because testing *is*
(a candidate for) the next stable Debian release. After that point,
there cannot be any more backports to the previous stable release,
because there is nothing in testing to backport from.

Some possible routes out of this hole:

* Exclude epiphany from testing sometime around freeze time, at which
  point its backports (if any) are EOL. Get it back into testing after
  buster is released.

* Persuade the release team that updating through the next 2+ years of
  new (stable) WebkitGTK+ versions is something they can include in stable
  updates with confidence, and that it is not going to break existing
  software in stable that uses them (including Evolution, Devhelp,
  Balsa, Anjuta, etc. as well as browsers) or grow new dependencies on
  lower levels of the stack like GTK+. The larger and more intrusive the
  changes are (particularly if other packages need changes to keep up),
  the more reluctant they will be.

  (A prerequisite for this is that someone needs to have enough time and
  expertise available to prepare the stable-updates.)

* Persuade the backports team to make an exception for certain packages
  that aren't in testing but only in unstable, and in particular Epiphany.

* Have a third-party apt repository with semi-official backports onto
  Debian stable, similar to mozilla.debian.net.

  (A prerequisite for this is that someone needs to have enough time and
  expertise available to operate it.)

* Make it possible to compile two parallel-installable copies of
  WebkitGTK+: a slow-moving copy that is used by random non-Web,
  non-security-sensitive apps like devhelp, and a fast-moving copy that
  is used by Epiphany (and anything else that renders untrusted HTML and
  can tolerate the possibility of regressions). Keep the slow-moving
  copy mostly static, fixing serious bugs with reviewable patches but
  not swapping between branches, analogous to what we do with
  WebkitGTK+ now (and also analogous to what we do with e.g. glibc, GTK+
  and dbus). Keep the fast-moving copy (and Epiphany) up to date,
  analogous to what happens with Firefox and Chromium.

  For example the slow-moving copy might be in the default linker path
  (/usr/lib/MULTIARCH) and the fast-moving copy might be elsewhere and
  used via -rpath, or they might both be in the default linker path but
  have different SONAMEs.

  (A prerequisite for this is that someone needs to have enough time and
  expertise available to prepare the stable-update for the fast-moving
  copy.)

None of those seem ideal but perhaps they give someone an idea?

    smcv