On Sat, 4 Jun 2022 at 18:54, Neal Gompa <ngomp...@gmail.com> wrote: > On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson <tdaw...@redhat.com> 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? > > > > Let me start with examples that I get *regularly*: Pagure fails to > install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown is > not available. KDE Plasma fails to install because of a mass of > missing dependencies. > > > To be crystal clear, I would like this fixed for at least the majority > of cases and gracefully fail when it can't be fixed. > > The issue is going to be that an RPM which changes outside subscriptions will probably be an auditable finding for a lot of sites. It is one of the reasons this has been considered bad form in the past and would probably cause a lot of requests that it be made optional, removed, OR epel black listed. It doesn't matter if we all think that would be a silly finding, changes like this are considered security issues at various sites especially if for the last 15 years, epel-release has not done something like that and so had been 'approved' for use.
At best I could see an optional side package `epel-release-enable-other-repo` or some similar name which just has these changes and is not pulled in by default and requires epel-release. Thus you could tell people to install `epel-release-enable-crb` and would get packages and if people have reports of broken packages you tell them to install this which will do the correct repo changes. -- 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@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
