Bug 1758470 - RFE: mark copr repo as module_hotfixes
Summary: RFE: mark copr repo as module_hotfixes
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Copr
Classification: Community
Component: frontend
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Kadlčík
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-10-04 08:55 UTC by Michael Mráka
Modified: 2019-12-06 10:41 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-06 10:41:21 UTC


Attachments (Terms of Use)

Description Michael Mráka 2019-10-04 08:55:28 UTC
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

Comment 1 Pavel Raiskup 2019-10-04 09:30:03 UTC
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?

Comment 2 Michael Mráka 2019-10-04 11:26:00 UTC
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.

Comment 3 Miroslav Suchý 2019-10-04 11:47:50 UTC
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).

Comment 4 Carl George 2019-10-28 17:49:59 UTC
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.

Comment 5 Mathieu Bridon 2019-11-03 19:25:44 UTC
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?

Comment 6 Alfredo Moralejo 2019-11-06 12:49:29 UTC
I'm hitting the same issue. Is there any workaround that i can use?

Comment 7 Alfredo Moralejo 2019-11-06 12:59:26 UTC
i think disabling a module during build would also work for me, is there any way to do it?

Comment 8 Pavel Raiskup 2019-11-06 14:13:42 UTC
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.

Comment 9 Pavel Raiskup 2019-11-06 14:15:23 UTC
Alfredo, perhaps your problem is related to bug 1758467.

Comment 10 Carl George 2019-11-06 14:24:02 UTC
> 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?

Comment 11 Alfredo Moralejo 2019-11-06 14:31:29 UTC
(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.

Comment 12 Pavel Raiskup 2019-11-06 14:39:15 UTC
> 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?

Comment 13 Pavel Raiskup 2019-11-06 14:44:39 UTC
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).

Comment 14 Alfredo Moralejo 2019-11-06 16:08:31 UTC
(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.

Comment 15 Jakub Kadlčík 2019-11-10 21:04:29 UTC
Modified in PR#1097

Comment 16 Mathieu Bridon 2019-11-20 23:09:07 UTC
Thank you Jakub for implementing this feature! 🤩️

Any ETA (even a rough one) for when this could be deployed?

Comment 17 Jakub Kadlčík 2019-11-21 00:19:46 UTC
> 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.

Comment 18 Pavel Raiskup 2019-11-21 05:25:55 UTC
(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.

Comment 19 Alfredo Moralejo 2019-12-05 09:39:21 UTC
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

Comment 20 Alfredo Moralejo 2019-12-05 12:09:43 UTC
(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!


Note You need to log in before you can comment on or make changes to this bug.