#200 Investigate whether EPEL packagers can get access to the BR repo
Opened 2 years ago by gotmax23. Modified a year ago

Currently, it is impossible to use the EPEL buildroot in mock (i.e. run it with --enablerepo=local), because the buildroot repodata is merged with the repodata of infrastructure's private RHEL mirror (https://infrastructure.fedoraproject.org/repo/rhel/*). I always run mock builds in Fedora with --enablerepo=local, because I want an environment that's representative of the buildroot, and I may want to access packages that are still in testing but have BR overrides. This issue also makes it impossible to do mock builds against a side tag repo. I don't think "use scratch builds" is a sufficient solution to this problem.

Can we investigate what whether this could be opened up to EPEL packagers? I'm not asking to make the RHEL mirror public on the internet, but perhaps it can allow members of the packager group (or maybe limited to the epel-packagers-sig) access? I'm not sure how this would work technically or whether this can be allowed, but I wanted to propose it to the SIG.


This is especially useful for EPEL 8, where the EPEL buildroot has certain modules flattened and enable by default. There is no way to replicate this setup locally, and it's a lot easier to just run --enablerepo=local instead of mucking around with mock configs and hoping you enable the right streams.

Metadata Update from @carlwgeorge:
- Issue tagged with: meeting

2 years ago

This has been requested before. After much going round and round with various parties, the answer has always been, no.
I believe the last time this came up was when Red Hat changed the developer license to 16 free licenses, and we got the same answer.
But I wasn't the one who did the asking. So I'll let those who did the asking answer this.

Metadata Update from @tdawson:
- Issue untagged with: meeting

2 years ago

Metadata Update from @tdawson:
- Issue tagged with: meeting

2 years ago

I obviously think this should be reconsidered. If building against RHEL is going to cause these kinds of problems, maybe we should consider building against one of the community rebuilds[^1], instead.

[^1]: I'm not seriously proposing this, as I know that building against RHEL is one of our tenets. My point is that building against RHEL itself shouldn't pose so many obstacles.

After discussion in the EPEL Steering Committee meeting, I am going to ask Red Hat if we can get the epel buildroots available.
There were many alternatives discussed in the meeting. Please put those here on this issue incase I get "no" as an answer.

I have talked to Red Hat, and it looks like the answer has changed a bit.
If we can figure out a way to check if a person has a RHEL subscription, free or otherwise, then they should be able to access the epel buildroots.

Thanks, @tdawson! That response is definitely better than the previous one. The real question is how we're going to validate subscriptions...

After discussion in the EPEL Steering Committee meeting, I am going to contact the subscription-manager team and find out if there is an API, or something, that would allow us to prove that we have a RHEL subscription.

I just re-read this and realized that I haven't contacted the subscription-manager team yet. Sorry about that. I''ve re-put it on my to-do list.

Metadata Update from @tdawson:
- Issue tagged with: blocked

a year ago

Metadata Update from @tdawson:
- Issue untagged with: meeting

a year ago

Login to comment on this ticket.

Metadata