The GNOME team intend to add an epoch to the babl and gegl libraries,
so I'm checking for consensus (Debian Policy ยง5.6.12.1). As usual with
epochs, this is a bad situation that I am trying to mitigate as much as
possible, rather than anything elegant or exemplary.
babl and gegl are 2D image libraries used by GIMP and GNOME Photos.
Historically, versions of these packages were shipped by the third-party
deb-multimedia.org apt repository. That would have been fine, except that
the maintainer(s) of deb-multimedia.org added an epoch to their versions.
It is not clear to me why this was done, and it breaks the versioned
dependency system, manifesting as frequent bug reports for gimp crashing
on startup.
For example, in #961993, gimp 2.10.18-1 requires the
gegl_rectangle_subtract() function introduced in upstream gegl 0.4.18,
and correctly has a versioned dependency on libgegl-0.4-0 (>= 0.4.22).
Unfortunately, the bug reporter had libgegl-0.4-0 version 1:0.4.16-dmo1
installed. That is an older upstream version 0.4.16, and so does not
have a gegl_rectangle_subtract() function, causing gimp to fail; but
as far as apt/dpkg are concerned, it satisfies the versioned dependency,
because the epoch says it is newer.
Jeremy Bicha contacted deb-multimedia.org and arranged for babl and gegl
to be dropped from the third-party repository, which fixes this problem
for new installations. However, existing installations will still have
their old versions of babl and gegl installed, and will no longer receive
security, bug-fix or feature updates from Debian (because as far as
apt/dpkg know, our versions of babl and gegl are older than the installed
copy).
My intention is to mitigate this by adding a 1: epoch to the versions of
babl and gegl in unstable, and adding the same epoch in the .symbols file
for all symbols introduced since the newest known versions of babl/gegl in
deb-multimedia.org (that's babl 0.1.74 and gegl 0.4.16, unless anyone can
tell me a newer version). This will make Debian's babl and gegl packages
supersede the obsolete versions from deb-multimedia.org. Additionally,
when dependent packages like gimp are next rebuilt, they'll pick up a
dependency on, for example, libgegl-0.4-0 (>= 1:0.4.22), causing the
version from Debian to be installed even if the user is doing a partial
upgrade.
In principle we could add the epoch to only the binary packages,
but it'll be a lot simpler and less confusing to add it to the source
package's version. Some of the binary package names (particularly
libbabl-dev and libgegl-dev) are going to be long-lived, so restricting
the epoch bump to binary packages would not help us to eliminate the
epoch in a future Debian release.
Note that I am specifically only doing this because deb-multimedia.org is
cooperating with us on this issue. Bumping the epoch to 1: in response
to a non-cooperative third-party repo would not be helpful, because
they would respond by bumping the epoch to 2: on their side and we'd
be back where we started; please do not interpret this as precedent for
having Debian packages reflect epochs added in third-party repositories
in general.
It would be a good general rule for third-party packaging repositories to
never add epochs without coordination with Debian. (However, this is of
course unenforceable, because the entire point of third-party repositories
is that they are not controlled by Debian or subject to its policies.)
smcv
