Re: Thoughts: epel-release auto-enable crb repo

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jun 4, 2022 at 3: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?
>
> 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://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

I have sympathy for the issue we are trying to solve, but I do not
think it's that big a deal.  Enabling crb is a documented part of
setting up EPEL.  Anyone having issues because crb isn't enabled
failed to follow the instructions.  Continuing to redirect people to
the instructions will eventually result in this being common
knowledge, and the instances of having to tell people about it will
continue to fall.  We can further reduce these instances by requesting
EPEL runtime dependencies be "promoted" from crb to baseos or
appstream.  In the mean time, it's not that much work to copy/paste
"the missing dependencies are in crb/powertools, follow the setup
instructions again" to the occasional bug report.

When we were first setting up the repo definitions for CentOS Stream
9, I suggested the idea of moving the crb repo file to a separate
package (centos-release-crb), with enabled=1 but not installed by
default.  This would allow epel-release to recommmend
centos-release-crb.  There was push back to this idea because there is
a desire for the "enable crb" action in CentOS Stream to look roughly
similar to how it works in RHEL (`dnf config-manager --set-enabled
crb` and `subscription-manager repos --enable
codeready-builder-for-rhel-9-$(arch)-rpms`).  Maybe we can revisit
this idea for CentOS Stream 10.

-- 
Carl George
_______________________________________________
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




[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux