On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson <tdawson(a)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.
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!