For Content Views I can enable “Solve Dependencies”. What is best practice and what is the impact other then it takes more time to public content views?
Some info here:
Thanks for the link but I guess I still does not really understand when I would want to enable “Solve Dependencies”.
Ex, I have one CV for normal CentOS 7 that include the standard repos + epel. Is there a reason to enable it for such a CV or just waste of CPU/time?
Typically you only want it when you have added filters to prevent wrong blacklisting from removing packages or even better to only whitelist one package and get all dependencies automagically included.
1 Like
Is this working? I’m trying to exactly this but no matter how many deps are listed in my single rpm file the CV only shows the package that I included in the filter. I would expect it to list all the packages that are listed as a dependecy in the filtered package. 
At least it should I have not tried it for a while and we now have Pulp 3 instead of 2 so it could be implemented differently, but as this is the expected way if it is not working it is a bug.
I kept trying again and again and the results vary. Sometimes I have more than 1 package but publishing the cv again using the same filter I get a different result. I’m still on pulp2. I have tried several times to update it but it always failed for various reasons.
Ok, I created a yum repo with some fakerpms with deps and after publishing a new CV version it works fine just as expected:
rpm1-1.0 - dep: rpm2
rpm2-1.0 - dep: rpm3
rpm3-1.0
This works fine when specifying one filter to include only rpm1. All deps are resolved. 
After publishing the first version I changed rpm3 version to 2.0 and added a dep for rpm4
rpm3 2.0 - dep: rpm4
rpm4
Even this works fine.
I took it one step further and created two additional rpms.
newrpm-1.0 deps: otherrpm
otherrpm-1.0
Even this works. So I can even include more than one rpm and the deps are resolved.
It even works when specifying versions in the rpm spec file:
Requires: totalrpm = 2.0
All these rpms resided in one single repo. In my orig CV there are plenty of repos and so I created a second repo “fakerpms2” with two rpm files one is a dep of a rpm from fakerepo and the other is a dep of the single rpm inside fakerpms2.
fakerepo:
otherrpm-4.0 - dep: totalrpm-4.0 (resides in fakrerpm2 repo)
fakerepo2:
totalrpm-4.0 - dep: somerpms-4.0 (resides in fakerpm2 repo)
And yes, works fine too.
It looks like the problem is somewhere else. My original CV is for SLES 15 and has many more packages to resolve 5000+ and over 20 repos included. Maybe it is crashing during the resolve process? Is there a way to debug this?
1 Like
I had no need to debug this in this depth, but perhaps some of the Katello developers know how to do it? Is this something @iballou can perhaps help or does know who can do so?
I investigated further the number of packages in the orig CV is enormous. 50000 packages in 50 repos. I created a fresh CV and started adding just a couple of the repos from the orig CV. It was working fine with ~ 20 repos. As soon as I added more ~ 40 in total it seems to fail as the CV now lists only 2 packages after publishing. Some of the repos have sync errors I will try to resolve the sync errors first and then try again.
Ok, instead of syncing the repos that had sync errors, I removed them from the CV an published again. Same result only 1 package. Reducing the repos to 24 and it works fine. I will now try to add 2-3 repos and see when it breaks.
@helloforeman what version of Katello are you running? Do you see any errors in /var/log/messages or perhaps warnings on the Dynflow tasks? I’m going to guess the Dynflow tasks are fine but figured I’d ask.
Dep solving should work for any number of repositories and any number of packages, module streams, errata, etc in the repositories.
If you’re able to get solid reproducer steps, we would really appreciate a bug report here! Katello bug tracker
Hi @iballou
I’m running version 3.18.3 with pulp2. I tried many times to upgrade to pulp 3 but this always failed. So I stick with pulp2 for now. I can reproduce it a way that now I have 2 CVs. One contains all the repos. The other one just parts of it. The one with fewer repos works fine. The one with all the repos not. I have now removed all repos from the cv that are not part of the other cv that works fine and now It seems to be working. I will have to check this again tomorrow. Maybe one of the repos is causing the problems. Weird.
Hi @helloforeman,
Ah, I just assumed that you were running Pulp 3. It could very well be a Pulp 2 bug. Since you have many repositories it could be related to cross-repo dep solving, but that is just a guess.
Ok, I have now added all of the remaining repos one by one, the results were strange as sometimes when adding a repo I finally had less packages in the CV. Now after adding all the remaining repos I have 2208 packages. This could be correct. I will try to deploy a fresh VM using this CV and see if there are any missing packages. And yeah, maybe it is a pulp2 bug. I should update soon…
Thanks for all your help so far.
1 Like
Ok, it seems that I’m affected by a bug in pulp. It seems that they have actually fixed the bug, but it is not yet released?