Description of problem: User should be able to mark repo as module_hotfixes which will set module_hotfixes=True in generated .repo file for this repo. This option will allow individual packages provided outside module streams to fix bugs and make them available on along with original module packages. Version-Release number of selected component (if applicable): 2019-10-04
Meh, when NEVRA and repo priroity isn't enough. Yeah, fun will be when more than one repo will have this flag. Do you want to have per-chroot or per-project knob?
I think per-project is enough. Dnf on Fedora 29+ / RHEL8 understands this option. You don't need to put it into epel[67] chroots and anyway yum ignores unknown options so it would not affect it. I'm just not sure about opensuse and mageia chroots.
Here is more verbose explanation how the filtering with hotfixes works https://dnf.readthedocs.io/en/latest/modularity.html#package-filtering (just notes for my future me).
On a related note, please provide a way to specify module_hotfixes when adding a copr as an external repository of another copr. Currently in the settings the external repositories field says it accepts a baseurl or a copr://user/project reference.
Is there a workaround, until Copr implements this feature? Any way at all to have a package in a Copr which overrides (with a more recent NEVR) a package from a module stream?
I'm hitting the same issue. Is there any workaround that i can use?
i think disabling a module during build would also work for me, is there any way to do it?
We discussed this bug report on last team meeting, and we came to conclusion that we only want to fix this for end-users (ie that we'll fix the repo files generated by copr if the project has this opt-in knob enabled). That said, so far we didn't plan to affect build-time of packages in copr. New issue is probably needed if you need that, too. But dunno. > i think disabling a module during build would also work for me, is there any way to do it? I don't think the repositories are designed so you can arbitrarily disable modular content.
Alfredo, perhaps your problem is related to bug 1758467.
> we'll fix the repo files generated by copr if the project has this opt-in knob enabled Will that work for the copr://user/project feature in the external repositories field?
(In reply to Pavel Raiskup from comment #9) > Alfredo, perhaps your problem is related to bug 1758467. I'd say not. Let me explain the case. A package foo-1.0.0 is provided in one of the modules included in rhel8 appstreams repo. I want to build bar-1.0.0 in copr and it requires foo-1.5.0. If i build foo-1.5.0 in the module, when i try to build bar-1.0.0 it skips foo-1.5.0 (because there is an older version in the module) and bar-1.0.0 fails to build.
> If i build foo-1.5.0 in the module, You mean in copr repository, but right - we need to solve build-time problems as well. To anyone, I'm curious. Is one option for both - the repo files and - build-time mock configs enough, right?
Btw., per IRC chat with Alfredo, we also need to propagate the module hotifix through external 'copr://project/foo' repositories (generated mock config during build time).
(In reply to Pavel Raiskup from comment #12) > > If i build foo-1.5.0 in the module, > > You mean in copr repository, but right - we need to solve build-time problems > as well. Yes, i meant in the copr repository. > > To anyone, I'm curious. Is one option for both > - the repo files and > - build-time mock configs > enough, right? I'm testing this locally using mock config from copr just by adding: module_hotfixes=1 In the copr_base repo in mock config.
Modified in PR#1097
Thank you Jakub for implementing this feature! 🤩️ Any ETA (even a rough one) for when this could be deployed?
> Any ETA (even a rough one) for when this could be deployed? My personal guess is, that we can make a release by the middle of next week.
(In reply to Jakub Kadlčík from comment #17) > My personal guess is, that we can make a release by the middle of next week. My bet is within 3 weeks. There are at least two other non-trivial issues that need to be solved before we deploy the current code in HEAD.
After latest release in copr i see this is still not implemented during build time I've marked "This repository contains module hotfixes" in an existing copr and i see it enables the option in the repo config file: https://copr.fedorainfracloud.org/coprs/g/openstack-sig/centos8-deps/repo/centos-stream/group_openstack-sig-centos8-deps-centos-stream.repo but not in the copr repo config in the mock for new builds: https://copr-be.cloud.fedoraproject.org/results/%40openstack-sig/centos8-deps/centos-stream-x86_64/01124240-python-six/configs/child.cfg
(In reply to Alfredo Moralejo from comment #19) > After latest release in copr i see this is still not implemented during > build time > > I've marked "This repository contains module hotfixes" in an existing copr > and i see it enables the option in the repo config file: > > https://copr.fedorainfracloud.org/coprs/g/openstack-sig/centos8-deps/repo/ > centos-stream/group_openstack-sig-centos8-deps-centos-stream.repo > > but not in the copr repo config in the mock for new builds: > > https://copr-be.cloud.fedoraproject.org/results/%40openstack-sig/centos8- > deps/centos-stream-x86_64/01124240-python-six/configs/child.cfg It's working fine for me now. Thanks for your support!