Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Niels Thykier]

Cyril Brulebois:
> Package: upgrade-reports
> Severity: critical
> Justification: makes upgrade from stable abort
> 
> [ X-D-Cc:
>   debian-release at lists.debian.org
>   pkg-java-maintainers at lists.alioth.debian.org
>   pkg-gnome-maintainers at lists.alioth.debian.org ]
> 
> Hi,
> 
> Regression spotted by Pere in some debian-edu job, but also seen since
> the 2nd of June in normal gnome chroot installation then upgrade from
> jessie to stretch:
>   https://jenkins.debian.net/view/edu_devel/job/chroot-installation_jessie_install_education-desktop-gnome_upgrade_to_stretch/
>   https://jenkins.debian.net/job/chroot-installation_jessie_install_gnome_upgrade_to_stretch/
> 

Hi,

Thanks for reporting this.

Timing being what it is, we need to act fast if we want to fix this for
stretch.  I have CC'ed maintainers of (presumably) relevant packages;
please be ready to upload a fix to your package if needed.

Long story short:
=================

 * dpkg reports a trigger cycle between gnome-menus and
   desktop-file-utils.

 * desktop-file-utils has an "interest" (implicit "-await") trigger, so
   it is plausible.  I have not verified the dependency relationship.

 * shared-mime-info also has an "interest" (implicit "-await") trigger.
   It may (or may not) be an accomplice to this issue.

 * gnome-menus only have "interest-noawait" and should therefore not be
   able to start the trigger cycle (but it can be part of one).

Things to do / research:
=======================

 * @desktop-file-utils: The trigger seems to be used for a cache.  Is
   there any reason for using the implicit "-await" trigger or can this
   cache update be deferred like the "man-db" cache can?

 * @shared-mime-info: The trigger seems to be used for a cache.  Is
   there any reason for using the implicit "-await" trigger or can this
   cache update be deferred like the "man-db" cache can?

 * @Andreas: Could you have a look at the upgrade ordering in this case.
   You are usually pretty good at spotting if we need Breaks, so I would
   be delighted if you could give it a go.
   (E.g. if gnome-menus need to break desktop-file-utils in jessie even
    if desktop-file-utils in stretch uses a "-noawait" trigger)


I have left the remaining parts of KiBi's mails below for the newly
CC'ed people.

Thanks,
~Niels


> I've managed to reproduce it locally with basically a debootstrap of
> jessie, installation of gnome, then switch sources.list from jessie to
> stretch, then update & upgrade & dist-upgrade.
> 
> I've bisected the archive using snapshot.debian.org and found out:
>  - 20170601T212625Z = last timestamp found to be OK;
>  - 20170602T033358Z = first timestamp to be KO.
> 
> Since logs are a bit too heavy for a bug report, I've uploaded them
> there:
>   https://people.debian.org/~kibi/jessie2stretch/gnome/
> 
> $timestamp.log is the output of the installation & dist-upgrade process,
> while $timestamp.log.clean is a cleaned version (with Get: lines edited
> to remove the package indice and the timestamp, then sort them by block,
> so as to avoid a huge diff).
> 
> Then I've generated upgrade.diff by diffing both clean versions:
>   https://people.debian.org/~kibi/jessie2stretch/gnome/upgrade.diff
> 
> This file consists mainly of some differences which should help us
> pinpoint the exact issue (first part of the diff), but also of a big
> diff at the end, since the OK log goes on with the install while the KO
> one is cut rather quickly. Actual error follows:
> | Unpacking default-jre-headless (2:1.8-58) over (2:1.7-52) ...
> | Processing triggers for libc-bin (2.24-10) ...
> | Processing triggers for hicolor-icon-theme (0.15-1) ...
> | Processing triggers for desktop-file-utils (0.23-1) ...
> | Processing triggers for man-db (2.7.6.1-2) ...
> | Processing triggers for libglib2.0-0:amd64 (2.50.3-2) ...
> | (Reading database ... 129883 files and directories currently installed.)
> | Removing openjdk-7-jre:amd64 (7u111-2.6.7-1~deb8u1) ...
> | Removing openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) ...
> | Removing tzdata-java (2017b-0+deb8u1) ...
> | Processing triggers for hicolor-icon-theme (0.15-1) ...
> | dpkg: cycle found while processing triggers:
> |  chain of packages whose triggers are or may be responsible:
> |   gnome-menus -> desktop-file-utils
> |  packages' pending triggers which are or may be unresolvable:
> |   gnome-menus: /usr/share/applications
> |   shared-mime-info: /usr/share/mime/packages
> |   desktop-file-utils: /usr/share/applications
> | dpkg: error processing package gnome-menus (--remove):
> |  triggers looping, abandoned
> | Processing triggers for desktop-file-utils (0.23-1) ...
> | Errors were encountered while processing:
> |  gnome-menus
> | E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> By looking at the diff before that, this might have been triggered (no
> pun intended) by the ca-certificates-java update, which included changes
> in the required java version, which might explain why this block was
> present in the OK log but no longer in the KO one?
> | -dpkg: openjdk-7-jre-headless:amd64: dependency problems, but removing anyway as you requested:
> | - ca-certificates-java depends on openjdk-7-jre-headless | java7-runtime-headless; however:
> | -  Package openjdk-7-jre-headless:amd64 is to be removed.
> | -  Package java7-runtime-headless is not installed.
> | -  Package openjdk-8-jre-headless:amd64 which provides java7-runtime-headless is not configured yet.
> | -  Package default-jre-headless which provides java7-runtime-headless is not configured yet.
> | -  Package openjdk-7-jre-headless:amd64 which provides java7-runtime-headless is to be removed.
> | - ca-certificates-java depends on openjdk-7-jre-headless | java7-runtime-headless; however:
> | -  Package openjdk-7-jre-headless:amd64 is to be removed.
> | -  Package java7-runtime-headless is not installed.
> | -  Package openjdk-8-jre-headless:amd64 which provides java7-runtime-headless is not configured yet.
> | -  Package default-jre-headless which provides java7-runtime-headless is not configured yet.
> | -  Package openjdk-7-jre-headless:amd64 which provides java7-runtime-headless is to be removed.
> | -
> 
> I don't see any immediate solutions (mostly because it's the first dpkg
> triggers cycle I encounter), but this looks like something that really
> should be fixed before the stretch release, hence the severity and the
> x-d-cc list.
> 
> 
> KiBi.
>