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

[Cyril Brulebois]

Niels Thykier <niels at thykier.net> (2017-06-15):
> 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
> "TRIGGER_PENDING" state.
>   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.

I can run tests but how is this going to help with a release on saturday?

Anyway, your analysis seems wrong, see below.

> 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
>    -noawait.
> 
>  * An upload targeting stretch for these two packages migrating them to
>    -noawait.
> 
>  * 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
> notice[1].
>   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.

That's wrong. The default-jre upgrade still happens, which means java 8
is installed; that just means java 7 can stay around for a little while
longer while the dist-upgrade is happening.

>  The user would explicitly have to install Java 8 and then uninstall the
> now unsupported Java 7 - that seems very unhelpful to me.

Nope. From the gnome upgrade log with ca-certificates-java “fixed”:
| Removing openjdk-7-jre:amd64 (7u111-2.6.7-1~deb8u1) ...
| …
| Removing openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) ...
| …
| Setting up openjdk-8-jre-headless:amd64 (8u131-b11-2) ...
| …
| Setting up default-jre-headless (2:1.8-58) ...
| …
| Setting up openjdk-8-jre:amd64 (8u131-b11-2) ...
| …
| Setting up default-jre (2:1.8-58) ...

While I can't say for sure my ca-certificates-java upload will fix all
upgrade paths, I'm quite confident the current upgrade paths is utterly
broken, and is very much less so afterwards, with no known downsides.

Again, I'm not going to pretend I'll be calling the shots here. But I
really fail to see a simpler way to get a net positive gain on this
topic.


KiBi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-freedesktop-maintainers/attachments/20170616/64c148f5/attachment.sig>