On Mon, 6 Jun 2022 at 10:44, Patrick Riehecky via epel-devel <epel-devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
I realize this is a bit of a pipe dream, but is there "some way" to
ship a repo file from EPEL that points to the crb repo(s)? Folks not
wanting it could block the package/not install weak deps. Getting the
right repos is a bit tricky but I figured I'd voice the idea...
Not really. The repo may be:
1. Upstream mirror system
2. Subscription tool CDN
3. Subscription local satellite
4. Subscription local repos.
5. Other proprietary software system which keeps track of repos
6. A system may not have access to CRB/Powertools for various reasons. [This is common from lack of space or cost or 'meh'.
7. ... you get the idea that there are going to be more variations. Get 10 computer sites, and you will have 10! (328800) solutions in no time.
subscription-manager can deal with most of those variations and dnf can deal with ones where a config file already exists.
Just for the record, dealing with the above variations was a continuing problem for the repositories before EPEL (Dag and such), and for EL5 which had repos which weren't generally shipped or available. It is only with EL6 and EL7, that we as a third party had an easy time of dealing with all the parts being shipped with upstream EL.
Pat
On Sat, 2022-06-04 at 13:52 -0700, Troy Dawson wrote:
> When I first created the EPEL issue to auto-enable crb repo[1] I was
> only thinking of CAN we do it. I wasn't thinking SHOULD we do it.
> We've come to the point that we actually can do it. But before we go
> down that road, I wanted to take a step back and ask, should we do
> it.
>
> The more I think about it, the more I think we shouldn't auto-enable
> the crb repo for epel8 and epel9. Here are my reasons why.
>
> 1 - The need to auto-enable crb isn't as big as it was before.
> At the time that I wrote that issue, I was getting quite alot of bugs
> / pings / emails about epel packages not being installable. I think
> on average about 2 a month.
> With epel being in fedora-docs, and with Carl's re-write of how to
> enable epel, that number has dropped significantly. I possibly still
> average one a month, but that's an average over a year, with most of
> them being last year.
> In short, I believe the documentation is better, and easier to find,
> allowing people to enable crb on their own, without automation.
>
> 2 - crb isn't an epel repo
> We really shouldn't be messing with other repo's that we, epel, don't
> own.
>
> 3 - We are taking the choice away from users
> After I stopped and thought about it, there are plenty of scenarios
> where people want epel for just one or two packages, which do not
> require crb.
>
> 4 - All the many small side cases.
> auto-enabling crb will have bugs. RHEL and it's clones are in too
> many odd places for us to not hit some odd use cases we didn't
> expect. We'd have to keep fixing the scripts.
>
> I could go into more explanation on each of those things, but in the
> end, I've talked myself out of wanting to auto-enable crb for epel8
> and epel9.
> But I also wanted to get others' thoughts before I close the bug and
> pull request.
>
> What do others think?
>
> Troy
>
>
> [1] - https://pagure.io/epel/issue/128
> _______________________________________________
> epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to
> epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_en-2DUS_project_code-2Dof-2Dconduct_&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza&s=d0B-lUzeMAZ-0S04uVby7ub-ORVZmAB6b5jp1yJRsuE&e=
>
> List Guidelines:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza&s=KUWCI2iU_-iPDDRDPyScLagKSycsfAiarhiTHIQYPR0&e=
>
> List Archives:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_epel-2Ddevel-40lists.fedoraproject.org&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza&s=P7pankG6ADB2aNPcSpD1QIXMv1ATMhIvP4ovYevs5rU&e=
>
> Do not reply to spam on the list, report it:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-2Dinfrastructure&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza&s=_cTkF9KBrWUy7DX9w20wQNnBshQg2EbgcQKLRhis6qY&e=
>
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
