Content-view Filter not working as expected - solve dependencies
Expected outcome:
Content-view filter uses all dependencies from package
Foreman and Proxy versions:
3.3 / 3.4
Foreman and Proxy plugin versions:
Distribution and version:
CentOS 7 / Rocky Linux 8.6
Other relevant data:
Hi,
I have tested this on Foreman 3.3 / Katello 4.5 under CentOS 7 and also on Foreman 3.4 / Katello 4.6 under Rocky Linux 8.6. In both cases I have installed all the latest updates.
I have a content-view with a couple of SLES repos and I have created a filter with a couple of rpms. These rpms are just dummy packages, they contain nothing but dependencies to other rpms. This is to ensure that a system has only specific versions of packages installed. Call it a baseline. This was working quite well, but since a few weeks we see unexpected behaviour from the filter. I just recently had to publish a new version of the content-view and noticed that some packages in the content-view have higher versions than specified in one of the dummy packages.
So I would expect to have zypper-1.14.52-150100.3.55.2 in my content-view but I got:
zypper-1.14.57-150100.3.64.1.x86_64
I’m quite sure that this working fine a few weeks ago. I don’t knwo if an update broke this or there is a new fuctionality that I’m not aware of, but it would be great to get this working again.
I even removed all the rpms from the filter and just tried with a single one but still I see higher versions than specified in the dummy rpm.
So it sounds like dependency solving is pulling in a version of zypper that’s too new?
Have you tried turning off dependency solving to ensure that the basic filter is pulling the correct RPMs into the repository? Knowing this would help triage the issue between Pulp and Katello. Pulp is 100% responsible for dependency solving, but Katello + Pulp together are responsible for the base content before dependency solving.
And you’re sure that nothing in the repository requires zypper-1.14.57-150100.3.64.1.x86_64 ?
I wonder if something got updated in your SLES repositories that is now causing the zypper 1.14.57 to be pulled in.
If there’s any way we can reproduce this ourselves let us know, it would make diagnosing way easier. Are the dummy RPMs ones that you made yourself?
So it sounds like dependency solving is pulling in a version of zypper that’s too new? <<
Exactly.
<< Have you tried turning off dependency solving to ensure that the basic filter is pulling the correct RPMs into the repository? >>
That is exactly the problem. I heavily rely on dependency solving since my filter only contains a handful of dummy rpm packages, that contain nothing but dependencies on other rpms to form the baseline for the machines.
<< And you’re sure that nothing in the repository requires zypper-1.14.57-150100.3.64.1.x86_64 ? >>
Hard to tell since the 5+ dummy packages have many dependencies and I also thought of this, but If I install the very same dummy packages that I use in the filter, on a SLES system it pulls in the correct version of zypper, so I assume this should also work fine in the filter?
<< I wonder if something got updated in your SLES repositories that is now causing the zypper 1.14.57 to be pulled in. >>
Yes the dummy packages have been updated. They are more or less updated frequently to include bug fixes security fixes etc. But I really have the feeling that it is no longer working, since I applied all the latest updates on my Katello machines.
<< If there’s any way we can reproduce this ourselves let us know, it would make diagnosing way easier. Are the dummy RPMs ones that you made yourself? >>
No, we are provided with these packages. I also don’t have the src rpms so that I could play around with them. What we also do have is a list of all the rpms with their exact versions, that form the baseline. I will now try to loop throgh this file and build a filter from it. It will take some time but I could disable dependency solving and hopefully the content-view will only contain the packages needed. Never the less it would be much more comfortable to have just a handful of rpm packages in the filter since these get updated quite frequently. And I will also try to build a small dummy package myself to test if this works.
I gotcha, I was more asking as a diagnostic step. If we can be sure that the base RPMs are filtered correctly, we can then assume that dependency solving is the actual issue.
It would be awesome to know if something else required the newer zypper. @dralley, if two packages require different versions of the same package, should the dependency solver pull in every required version of that package?
I suppose then we could try testing a basic scenario where two packages require different versions of the same dependency package and see what happens.
sorry I haven’t had time to look into this again. For now I just used a simple script that loops through the list of all the packages that should be included in the repo and added them as a filter. This is a quite slow process but I end up with a perfect repo for now. Never the less I like your way of moving forward. I will see If I can spare some time this week to build some dummy rpms and report the results.
