pulp
Copying uploaded RPMs with dependency solving doesn't copy dependencies
Version python39-pulpcore-3.18.10-1.el8pc.noarch python39-pulp-rpm-3.17.10-3.el8pc.noarch
Describe the bug Copying content from a repository with uploaded RPMs and dependency solving on seems to not copy the dependencies.
To Reproduce Steps to reproduce the behavior:
-
Create a repo and upload the attached RPMs in this archive: vim-rpms.zip
-
Try to copy vim-enhanced to a new repository with
dependency_solving=true -
See that the dependencies are not copied.
Note: I've been reproducing this in Katello. If it's not reproducible otherwise, we can make a Katello reproducer environment.
Expected behavior vim-enhanced plus its dependencies should be copied over.
Additional context I think this has to do with either the files being uploaded, or for some reason the files existing in the source repo by themselves. I tried copying vim-enhanced from the AlmaLinux repositories in Katello, and dep solving did seem to bring in the vim dependencies.
https://bugzilla.redhat.com/show_bug.cgi?id=2132472
Related upstream thread: https://community.theforeman.org/t/solve-dependencies-does-not-work/30682
Is someone working oin this @dralley ? Looks like it's the reason for a feature currently broken in katello.
It's on my list to get to, but new items keep popping up at the the front of that list : (
I will say that we have discovered that repo-side dependency solving cannot work perfectly even in theory, there are cases where we simply do not have enough context to be able to do the right thing 100% of the time.
My recommendation is to turn it off, and write your Katello filters in such a way that errata you don't want (e.g. everything after date X) are excluded (and everything else included) rather than the other way around.
That seems to be the configuration where things work best, on average.
Do you have an update for this issue @dralley ?
If I understand it correclty, this issue is the root cause that dependency solving in katello doesn't work right now @ianballou ?
My recommendation is still the same, the way dependency solving works when done at the whole-repo level is prone to breakage - even in theory. There are some specific issues that could potentially be resolved but, knowing the above, we're trying to push users in the direction of just not using it.
The biggest original motivation for dependency solving was that it would (probably) pull in missing packages on occasions where the errata forgot to include them, but that wasn't 100% either and that problem (falsely-incomplete errata) has mostly disappeared.
@dralley the issue seems to specifically affect uploaded RPMs. If the same RPMs are synced in rather than uploaded, the dependencies get copied properly.
So dependency solving seems to be correct, but throwing uploaded content into the mix throws it off.
If that's a use case that never worked, let us know. It sounds like something that very few people likely have tried before.
If I understand it correclty, this issue is the root cause that dependency solving in katello doesn't work right now @ianballou ?
This doesn't sound right, the issue here is related only to uploaded RPMs. Dependency solving (as far as I know) isn't generally broken.
Sounds like the katello feature should then be removed @ianballou
We're advising folks not to use dependency solving if possible, but since so many users are used to it being there it's quite hard to plainly remove. We're soon hoping to make it turned off by default in more places. Dependency solving is usually quite helpful, it's just that when issues do arise, they're very difficult to debug.
So dependency solving seems to be correct, but throwing uploaded content into the mix throws it off.
That is... weird. Very weird. There's nothing about dependency solving that would know whether the package has been uploaded or not.
The originating-BZ has been CLOSED-INSUFF. I'm going to close this as well. If the originating ticket is reopened, we can revisit.
