On Sat, Jun 4, 2022 at 21:17 Manuel Wolfshant <wolfy@xxxxxxxxxxxxxxxxxx> wrote:
On 6/5/22 03:47, Stephen Smoogen wrote:
On Sat, 4 Jun 2022 at 18:54, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
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.
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.
I really do not want to bash anyone but for _ages_ and I really mean a long long time, Ubuntu and Debian know how to be friendly and fail gracefully, suggesting the exact command that must be used when a package fails to get installed because it is not found. It's not like it is so hard to tell the user to run "dnf config-manager --set-enabled $whateverrepoisneeded" or even better continue with " Do you want me to enable it for you now ?"
That is built into how deb and apt are written versus rpm. Doing out put like this in rpm’s breaks a lot of automation which is built around the idea that rpm are not saying things like that.
_______________________________________________
wolfy
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
