On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson <tdawson@xxxxxxxxxx> 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. I get variations of these two examples at least *once a month*. Sometimes even filed as Bugzilla reports. It takes time away from me doing normal work. I can easily imagine other contributors having similar burdens. For me, this is absolutely an annoying issue that creates enough overhead to be worth fixing. Once you get to this level, "crb isn't an epel repo" and "we are taking the choice away from users" is silly, because we absolutely depend on crb being enabled and users don't know how we cross into RHEL repos for dependencies. Heck, many packagers building for EPEL don't. Even worse, some RHEL folks don't realize how difficult it is to use RHEL without CRB. The worst thing that could happen with auto-enabling is that it fails to run. We can easily just put some output when it fails to tell users that CRB/PowerTools could not be auto-enabled and for users to ensure it's enabled. But *not* attempting to auto-enable it means we accept that RHEL's bad choices on this are impossible to work around. It would be more tolerable if CentOS Stream had CRB content available by default like how CentOS Linux 7 has the content from the RHEL 7 optional channel available by default. Sadly, every attempt to make that happen has failed. Thus, CentOS Stream and RHEL clones (which are effectively clones of CentOS Stream) don't do it, so we have a usability problem that causes pain for contributors and users. 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
