Incorrect propagation chain reporting on profile collision

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.

This patch series fixes issue #63319, making propagation chains leading to

profile collisions be reported properly. It does this by having

'check-for-collisions' fill in the &profile-collision-error with the manifest

and the lowered versions of the entries in question, and (guix ui) derive

parent information from the manifest. It then removes the now-unused 'parent'

field of <manifest-entry>.

Ulf Herrman (3):

profiles: include non-lowered entries and manifest in collision error.

ui: derive parents of profile collision entries from manifest.

profiles: remove `parent' field.

guix/inferior.scm | 36 ++++-----

guix/profiles.scm | 183 +++++++++++++++++++++++++---------------------

guix/ui.scm | 32 ++++++--

3 files changed, 142 insertions(+), 109 deletions(-)

--

2.39.1

This provides the necessary information for (guix ui) to accurately determine

the actual entries causing the collision. The entries alone aren't enough,

since they inherit their parent (singular!) field from whatever it happened to

be before any manifest transaction was applied. The lowered variants are

included because (guix ui) needs them for reporting store paths, and the

non-lowered variants are included so that the proper parents can be derived

from the included manifest, which must contain them.

We also add and export a convenience procedure for finding the parents of menu

entries in a particular manifest.

profile-collision-error-conflict-lowered, profile-collision-error-manifest):

new fields.

(check-for-collisions): populate them.

(manifest-entry->parents): new procedure.

---

guix/profiles.scm | 60 ++++++++++++++++++++++++++++++++++++++---------

guix/ui.scm | 4 ++--

2 files changed, 51 insertions(+), 13 deletions(-)

This fixes https://issues.guix.gnu.org/63319.

use manifest-entry->parents and the manifest included with the collision to

get the parents.

---

guix/ui.scm | 30 +++++++++++++++++++++++++-----

1 file changed, 25 insertions(+), 5 deletions(-)

This field was only present for consumption by (guix ui) when reporting

propagation chains that lead to profile collision errors, but it is only valid

in general with respect to a single manifest. (guix ui) now derives parent

information by itself with respect to an explicit manifest, so this field is

no longer needed.

(package->manifest-entry, sexp->manifest): do not populate it.

(manifest->gexp): adjust match specifications to account for its absence.

nonexistent parent field.

---

guix/inferior.scm | 36 ++++++--------

guix/profiles.scm | 123 +++++++++++++++++++---------------------------

2 files changed, 67 insertions(+), 92 deletions(-)