-
Notifications
You must be signed in to change notification settings - Fork 198
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
Add rpm-ostree support for modules #1435
Comments
I haven't tried, offhand my understanding is we'd only support the default streams, although I'm not even sure of that. Enhancements here block on rebasing libdnf but that's only the start...some of what libdnf does today is wrong for rpm-ostree (like the sqlite database in |
Marking this as hard. Let me know if that needs to be adjusted. |
The libdnf rebase is done now! Note there is a hack in fedora-coreos-config to disable modular repos we'll want to drop once rpm-ostree becomes module aware. |
Related: #1404 (comment). I haven't looked into this yet, so not sure how much work it'll actually be. At the very least though, if we don't want to block the next release on this, we should see if we can just tell libdnf to be module-unaware as it was before the rebase. |
For now, we don't natively support modules. But we still want to be able to install modular packages if the repos are enabled, but libdnf automatically filters them out. So for now, let's tell libdnf that we do want to be able to see them. Related: coreos#1435
I was looking at this today and how Anyway, short term fix in #1797 at least so we can get a release out soon. |
Was chatting with @imcleod about this. One thing we need to look into here is that libdnf should be overriding packages from the default stream if a modular repo is enabled, even if it's older than the same RPM from a non-modular repo. It doesn't seem like that's what we're seeing today. |
Current state of this is best summarized in Basically, modules are implemented by filtering the repodata which we don't do, so rpm-ostree will tend to just pick the highest NEVRA. In some cases this will work fine, in others it won't. |
This is a follow-up hack to coreos#1797 to force libdnf to let us use modular packages as if they were regular packages until we actually support modules correctly (coreos#1435). A repo marked as a modular hotfix means that libdnf doesn't try to filter out modular RPMs from the repo as it usually does. Resolves: https://pagure.io/releng/failed-composes/issue/717
This is a follow-up hack to coreos#1797 to force libdnf to let us use modular packages as if they were regular packages until we actually support modules correctly (coreos#1435). A repo marked as a modular hotfix means that libdnf doesn't try to filter out modular RPMs from the repo as it usually does. Resolves: https://pagure.io/releng/failed-composes/issue/717
This is a follow-up hack to #1797 to force libdnf to let us use modular packages as if they were regular packages until we actually support modules correctly (#1435). A repo marked as a modular hotfix means that libdnf doesn't try to filter out modular RPMs from the repo as it usually does. Resolves: https://pagure.io/releng/failed-composes/issue/717
It seems libdnf now has a C interface for modules: rpm-software-management/libdnf#874 (comment) |
out of curiosity, does there exist a timeline that this may be implemented in @dustymabe @cgwalters ? |
Blocked on rpm-software-management/libdnf#874 (comment) |
This is fixed now by #2760! 🎉 |
See devel list thread. It looks like cri-o might start going modular. Can rpm-ostree support this (I know we inherit most functionality from dnf libraries, but there are probably some things to consider).
I saw #744 but this question wasn't really addressed there I don't think.
The text was updated successfully, but these errors were encountered: