On Sat, Jun 4, 2022 at 21:17 Manuel Wolfshant <wo...@nobugconsulting.ro> wrote:
> On 6/5/22 03:47, Stephen Smoogen wrote: > > > > 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. > > > 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@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 > -- 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
