Bug 1758470

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!