# Dependency Solving & Katello

## Action items:

* Observation: https://cdn.redhat.com/content/dist/rhel8/
* Do 8.4, 8.6 etc. tools present here get updates or are they snapshots?
* https://access.redhat.com/articles/1586183
* Each dot-release repository contains ALL errata (security, bugfix and enhancements) from the GA of that product until the next minor release. At this point, these repositories receive no further errata.
* Does this meet the need of our customers in some of the clone-by-date use cases?

## Background

Katello / Satellite have a feature called incremental update. Users wanted to cherrypick individual errata to older versions of the OS, often because some third party software is only supported on a specific point release, but they want their security updates anyway.

"clone-by-date" existed to fill this gap. You were allowed to pick "RHEL as of 6.3" and build your own EUS. This has never really worked perfectly and it results in a lot of support cases and after-the-fact hacks.

From there it got copied into Katello / Pulp, except worse because of cross-service traffic and expanded surface area.

What the users really wanted at the end of the day is generally one of these 4 use cases: https://hackmd.io/@ggainey/depsolving

Where depsolving comes in: What users want is to install particular errata, but
* errata were sometimes incorrect, and didn't include all of the RPMs which they were meant to, which led to packages having broken dependencies in the repo. Depsolving was meant to address this.
* installing security-errata from after the desired date could/will result in the RPMs for those errata, requiring RPMs released after the desired date

Spacewalk clone-by-date impl: https://github.com/spacewalkproject/spacewalk/blob/master/utils/cloneByDate.py#L479

## Problems

* Correctness
* In practice, when users have issues with depsolving we usually recommend approaches to accomplish their goal without depsolving
* The context in which we are using libsolv is not the context in which it was intended to be used. Trying to do dependency solving at the repository level requires a ton working around libsolv's core assumptions
* Making it work perfectly at the scope we use it is pretty much impossible: https://bugzilla.redhat.com/show_bug.cgi?id=2070537#c15
* TL;DR: If packages X, Y, and Z are co-packaged together (think: "librepo", "python3-librepo", "librepo-docs") and package A depends on package X but not package Y, then the resulting repo post-depsolving may upgrade only package X and break its existing version of dependency Y.
* There are maybe workarounds for this but it would cut against every recommendation we've been given and be way way more outside of the beaten path than we already are.
* Performance
* Dependency solving takes a long time relative to a lot of other tasks, and is particularly IO-intensive since it has to pull so much metadata from the database
* https://github.com/pulp/pulp_rpm/issues/2298
* katello is doing a ton of work in its db, and passing the resulting (gigantic) list of RPM-hrefs to Pulp. A higher-level communication between katello and pulp would let Pulp do the heavy lifting directly and WAY more efficiently
* Maintainability
* Dependency solving is fairly opaque and extremely difficult to debug
* Future staffing concerns, need to reduce complexity as much as possible
* RHEL and libsolv version conflicts
* TL;DR the fact that both RHEL and Satellite use libsolv presents an problem. Satellite shipping libsolv as part of a module can break RHEL8 installs.
* https://issues.redhat.com/browse/SAT-14019

## What functionality our users use and expect to have

There are limits to what functionality we can remove. Our users have certain workflows and we cannot outright break and remove those workflows.

Which workflows use RPM repo-to-repo copy? Which workflows use dependency solving specifically?

* See https://hackmd.io/@ggainey/depsolving for high-level usecases

## What can we do to move away from dependency solving?

We may want to slowly transition over the course of multiple releases

e.g. Replace the current copy options with a simpler set, but retain the current options under an "advanced" menu?

## Possible/likely responses

* turn off depsolving-by-default everywhere
* document better best-practices for how to do filtering in ways that are more likely to be correct/performant
* "filter-out-after" better than "filter-out-before"
* "use point-release Libraries instead of main RHEL Library"