Bug#978588: Processed: Re: Bug#978588: firefox: should depend on either libgdk-pixbuf package

[Simon McVittie]

On Tue, 29 Dec 2020 at 21:39:07 +0000, Debian Bug Tracking System wrote:
> > reassign 978588 libgdk-pixbuf2.0-dev

Please remember to cc the target package's packages.debian.org address
when reassigning.

Copy/pasting from the mail that reassigned this bug, sorry for breaking
threading:

David Tulloh wrote:
> The libgdk-pixbuf packages are migrating from
> libgdk-pixbuf2.0-0 to libgdk-pixbuf-2.0.0
> 
> The most recent firefox package has matched this name transition.
> 
> However many other packages have not yet made the transition, causing
> clashes which require their removal. Popular packages include
> mutter and gimp. This significantly impacts the overall usability of the
> system.

The bug report did not include details of the system on which you are
installing Firefox. Is it Debian testing/unstable, or something else?

Please explain in more detail what the problem is here? We have
provided a transitional libgdk-pixbuf2.0-0 package which does not
conflict with libgdk-pixbuf-2.0.0, so you should be able to upgrade
to libgdk-pixbuf2.0-0 (>= 2.40.2) and libgdk-pixbuf-2.0-0 (>= 2.42),
which will satisfy both the "old" and the "new" dependency. Is there a
reason why you cannot do that?

(This will also pull in libgdk-pixbuf-xlib-2.0-0, for parity with the
old libgdk-pixbuf2.0-0 package. That's not a bug. gdk-pixbuf-xlib will
have to remain installed as long as you have at least one package that
might need it, and any package with a dependency on libgdk-pixbuf2.0-0
might need it.)

Mike Hommey wrote:
> I think that rather than having reverse dependencies handle this all one
> by one, this should be handled by libgdk-pixbuf itself, via its symbols
> file, leaving it to dh_shlibdeps to add the desired deps.

That's what we originally did, but according to
https://bugs.debian.org/975904 the resulting dependency cycle between
gdk-pixbuf and gdk-pixbuf-xlib is a problem for some reason, although
the bug reporter unfortunately didn't clarify whether this is the case
even though there is a non-circular alternative.

    smcv