Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use RHEL9/CentOS stream dependencies for content resolver #490

Open
voxik opened this issue Feb 16, 2021 · 13 comments
Open

Use RHEL9/CentOS stream dependencies for content resolver #490

voxik opened this issue Feb 16, 2021 · 13 comments

Comments

@voxik
Copy link
Contributor

voxik commented Feb 16, 2021

It would be nice if content resolver was smart enough to use RHEL9/CentOS stream to resolve its dependencies instead of placeholders. E.g. for git-lfs, there is following placeholder:

package_placeholders:
git-lfs:
srpm: git-lfs
description: Git extension for versioning large files
requires:
- git-core
buildrequires:
- perl-Digest-SHA
- perl-Test-Harness
- git

But it would be much easier, if content resolver knew where to ask RHEL9/CentOS stream for the real values from the package, which is not inherited into ELN.

@voxik
Copy link
Contributor Author

voxik commented Feb 16, 2021

Maybe it would be good start if there was tool, which could based on SRPM/RPMS provide content for the placeholder section, so this would be less manual (error prone) process.

@asamalik
Copy link
Contributor

That's already possible, you just need to split the workload into two.

The one for ELN will only use the "eln" label, and the other one only "c9s".

@voxik
Copy link
Contributor Author

voxik commented Feb 16, 2021

That's already possible, you just need to split the workload into two.

Oh, could you be please more specific? How we could do that with the git-lfs for example?

@asamalik
Copy link
Contributor

Copy the existing one to a second file, perhaps sst_cs_apps-scm-eln.yaml and only leave the "eln" label (remove the "c9s" one). That will now be just ELN.

In the other one (sst_cs_apps-scm.yaml) remove the "eln" label and only keep the "c9s". And move all placeholders into "packages":

...
packages:
- git-lfs
...

@asamalik
Copy link
Contributor

I split these two for example:

sst_cs_infra_services-varnish-eln.yaml

sst_cs_infra_services-varnish.yaml

@voxik
Copy link
Contributor Author

voxik commented Feb 16, 2021

Thx for explanation. @opohorel could you please try to adjust the git-lfs? Not sure we have it in CentOS streams though, something to explore.

opohorel added a commit to opohorel/content-resolver-input that referenced this issue Feb 16, 2021
@opohorel
Copy link
Contributor

I made a PR with proposed change. Could you please review it and merge if everything is ok. Thank you

@voxik
Copy link
Contributor Author

voxik commented Feb 18, 2021

Where I can see the impact of the PR above? Because I am afraid I don't understand what it actually does. I thought that we will be able to completely get rid of the placeholder ....

@voxik
Copy link
Contributor Author

voxik commented Feb 18, 2021

Now I probably realized how this is supposed to work. The c9s will be created based on CentOS stream as soon as it is available. Where ELN is actually RHEL10.

Anyway, I'd still prefer if the content resolver was more flexible and allowed to use the some "real" package dependencies instead of completely manual specification of them.

@asamalik
Copy link
Contributor

Yes, exactly.

You can either use a real package, or this placeholder that you need to define manually. Are you hoping for something in between? What would that be?

@voxik
Copy link
Contributor Author

voxik commented Feb 18, 2021

Yes, as I said, I'd hope that there can be exception in ELN content set, which would take the dependencies from C9S. Or there would be at least tool to (re)generate the placeholder from (S)RPM.

@voxik
Copy link
Contributor Author

voxik commented Feb 23, 2021

Yet another idea, would it be possible to filter the dependencies?

@voxik
Copy link
Contributor Author

voxik commented May 24, 2021

This is related to #391 and I'd appreciated if this was improved.

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

No branches or pull requests

3 participants