Skip to content

feat: structured hints for unsatisfiable conflicts#234

Open
baszalmstra wants to merge 1 commit into
prefix-dev:mainfrom
baszalmstra:feat/conflict-hints
Open

feat: structured hints for unsatisfiable conflicts#234
baszalmstra wants to merge 1 commit into
prefix-dev:mainfrom
baszalmstra:feat/conflict-hints

Conversation

@baszalmstra

Copy link
Copy Markdown
Contributor

When a solve fails, resolvo can render a human readable explanation, but it offers nothing a program can act on. That makes it hard to build helpful tooling on top, such as suggesting a fix for a misspelled package name or pointing out that a package is not available for the current platform.

This adds a way to get the causes of a conflict as structured data, next to the existing rendered message. Each hint describes a single cause: an unavailable package, a version that does not match, candidates that were all excluded, incompatible requests, an unfulfillable constraint, or a lock. The existing error message is unchanged.

Tested with snapshots covering each kind of hint.

Add Conflict::hints, which returns machine-actionable explanations of why
a solve failed alongside the existing rendered error message. Each hint
describes a single cause, such as an unavailable package, a version that
does not match, candidates that were all excluded, incompatible requests,
an unfulfillable constraint, or a lock.
@baszalmstra

Copy link
Copy Markdown
Contributor Author

@dralley What do you think of this?

@dralley dralley left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it looks basically good, but FWIW my review isn't worth that much, I haven't spent much time on the "non-happy path" of resolving and my experience with the internals is still pretty limited.

I read up on the theory a bit a few years ago to do some work with libsolv around 2020 (wow, forever ago) and this is pretty much my first crack at it since then (and my goal is basically to replace what I wrote back then, because it was and is awful [0])

I can try pulling it locally to play with it a bit


(unrelated tangent)

A little context on [0] and why it's cursed:

My job is working on repository management tooling, mostly RPM repository management. Customers for various reasons and in certain environments don't trust updates w/o putting them through a staging / prod test cycle, so they put our tooling between the CDN and their servers.

One thing they want to do, which is honestly problematic but it's nonetheless what they want to do, is apply individual errata / updateinfo / advisories to their repos for downstream consumption, and sometimes that has dependency implications.

And so we were trying to do this with libsolv, and libsolv forces the concept of an "installed" package set, and so trying to use that with entire repos at a time is absolute torture - it's multiversion+++ because the "installed" set will include multiple packages for most package names, and many different repos can be involved both on the input and output side because e.g. AppStream and other layered repos are not dependency-closed without BaseOS, so there had to be an mapping of input repos to output repos alongside libsolv...

Horrible. I'm hoping the fact that resolvo is less opinionated makes some of that mess avoidable. But for now I'm just doing the simple & normal stuff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants