On Sat, 2022-06-04 at 20:47 -0400, 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. > This won't be ready until EPEL 10 or even 11, but one thing I've discussed with the DNF maintainer is the possibility of having something like /etc/yum.repos.d/reponame.repo.d/ where you can drop overrides, similar to how you can drop overrides for systemd unit files. That would allow epel-release to just ship an override for crb.repo that toggles enabled=1, without messing with config files (which I hate, because that means newer crb.repo changes won't be picked up). Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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
