bug#63319: Incorrect propagation chain reporting on profile collision

[Ulf Herrman <striness@tilde.club>]

[-- Attachment #1: Type: text/plain, Size: 3762 bytes --]

A <manifest-entry> has a `parent' field that contains a promise that
returns either #f or another <manifest-entry>.  This is somewhat
incomplete information - a given entry can be a propagated-input to
multiple entries, so there can actually be multiple parents.  Given that
this is only used for tracing a propagation chain to display to the
user, though, that shouldn't be a problem.  What is a problem, though,
is that this field is determined when the manifest is read in and
remains static thereafter.  To demonstrate this, consider the following
example:

User installs package A1, which propagates B1.  User also installs
package C, which also propagates B1.  Later the package definition for A
is updated with a newer version, A2, and this propagates a newer version
of B, B2.  User runs 'guix pull', and subsequently runs 'guix package
-u'.  Note that C is unchanged and still propagates B1.  Guix sees that
the proposed new manifest contains A2, C, B1, and B2, and properly
detects that B1 and B2 represent a collision.  It traces B2 back to A2
correctly, and then goes to hunt down what propagated B1.  What happens
next depends somewhat on the arbitrary ordering of entries in the
manifest, but it is entirely possible that the parent recorded for B1 is
not C, but A1, even though the proposed new manifest doesn't even
contain A1.

So you end up with bizarre error messages like this:

-----------------------------------------
$ guix package -u certbot
The following package will be upgraded:
   certbot 1.28.0 → 2.3.0

guix package: error: profile contains conflicting entries for python-cryptography
guix package: error:   first entry: python-cryptography@40.0.1 /gnu/store/bcixgv8vg9bz6gyvijavqiha77h17icv-python-cryptography-40.0.1
guix package: error:    ... propagated from python-josepy@1.13.0
guix package: error:    ... propagated from python-acme@2.3.0
guix package: error:    ... propagated from certbot@2.3.0
guix package: error:   second entry: python-cryptography@3.4.8 /gnu/store/2kz701xhwvcswdp4dj3fd7v86v2ra70x-python-cryptography-3.4.8
guix package: error:    ... propagated from python-josepy@1.13.0
guix package: error:    ... propagated from python-acme@1.28.0
guix package: error:    ... propagated from certbot@1.28.0
hint: You cannot have two different versions or variants of `certbot' in the same
profile.
-----------------------------------------

This happens because the collision check is performed on the new
manifest, and the parent fields are leftover from the old manifest.

Ultimately, the parent field is just an optimization - it can always be
re-derived from a manifest, and indeed, when a <manifest-entry> is
shared across multiple manifests, *must* be re-derived with respect to a
given manifest in order for it to make sense.  I propose that we remove
the 'parent' field entirely and modify &profile-collision-error so that
it also reports the manifest the collision occurred in.  (guix ui) can
then use this to provide more complete (and also accurate) error
messages.  Note that at present check-for-collisions actually can report
manifest entries that aren't "part of" *any* manifest, since they're
freshly created by lower-manifest-entry.



Tangentially related: it's worth noting that only showing two
propagation chains tends to lead to frustrating "whack-a-mole"-style
package transactions, since a decision about which package to keep,
remove, or upgrade has to be made before the next collision source can
be found.  We should probably add a profile mode to 'guix graph' that
shows the propagation graph for a proposed new profile manifest, or at
least let 'guix package' show all collisions when invoked with higher
verbosity.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]