Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers
niels at thykier.net
Thu Jun 15 20:31:00 UTC 2017
> [ added Guillem to the recipients, he is the expert for trigger cycles ]
> [ added Doko to the recipients, since #863820 is a possible solution ]
> [ therefore resending a full-quote ]
> On 2017-06-11 12:00, Niels Thykier wrote:
>> Cyril Brulebois:
>>> Package: upgrade-reports
>>> Severity: critical
>>> Justification: makes upgrade from stable abort
> Switching desktop-file-utils or/and shared-mime-info to -noawait
> triggers does not solve the problem.
Guillem and I have been talking about this over IRC and have a theory.
Basically, jessie's verison of desktop-file-utils and shared-mime-info
have "-await" triggers (implicit) which will push other packages into a
Once they are in that state, the "damage" is done and those other
packages will no longer satisfy dependencies until the trigger has been
processed. Notably, dpkg is unable to /undo/ this state even if the
trigger changes from -await to -noawait during the upgrade.
* If this holds, then changing the desktop-file-utils and
shared-mime-info triggers *in stable* to -noawait should make the
problem go away.
* I realise it is unfeasible to implement in Debian by Saturday, but
it would help us understand the root cause of the problem.
- Tests to confirm/disprove this would be very welcome.
If this holds, then to fully resolve the problem, we will need 3 things:
* A stable update to jessie for these two packages migrating to
* An upload targeting stretch for these two packages migrating them to
* A "big magic hammer" work around for stretch for r0
- OR a release-notes remark to pull upgrades from jessie
- OR ...
Obviously, the above possibly ignores some time constraints.
Furthermore, the only thing remotely resembling a "big magic hammer"
atm. seems to be #863820, which we are unwilling to do with such short
I know that there was an upload to undo the changes in the java
packages, but AFAIUI, it basically means that Java will not be upgraded.
The user would explicitly have to install Java 8 and then uninstall the
now unsupported Java 7 - that seems very unhelpful to me.
 We do have an another possible "big magic hammer", but it is even
less pretty and is called "Pre-Depends". As I recall, Pre-Depends are
handled specially by apt so it runs them in smaller bundles before the
main upgrade. We can almost certainly abuse this to work around the issue.
However, I hardly imagine that most of you will applaud that.
More information about the Pkg-freedesktop-maintainers