Description of problem: Please branch and build the_silver_searcher for epel10. Thanks!
Hi! Per https://github.com/ggreer/the_silver_searcher/issues/1539 can we remove the_silver_searcher from fedora . I mostly use rg and ack anyway. What do you think?
Well that's drastic! I'm quite a fan of ag/the_silver_searcher, as are my colleagues.
(In reply to Tim Skirvin from comment #2) > Well that's drastic! I'm quite a fan of ag/the_silver_searcher, as are my > colleagues. Hi Tim! In that case - can *you* contribute a merge request? i'll try to get it reviewed and applied as soon as I can.
(In reply to Tim Skirvin from comment #2) > Well that's drastic! I'm quite a fan of ag/the_silver_searcher, as are my > colleagues. OK. I've updated the_silver_searcher release 13 in fedora43 (= current rawhide) to build using pcre2-devel. You may wish to test it. Thanks!
> Well that's drastic! It's really not. The last commit upstream was in 2020, and the last tag was in 2018. Currently there are 439 open issues and 123 open pull requests. The pull request to add PCRE2 support was opened in 2016, never got a response from the maintainer, and was closed by the submitter in 2018. Shlomi was able to add PCRE2 support by borrowing the Debian patch (which itself is based on that closed upstream PR), but that's not a very sustainable approach for what appears to be a completely inactive project. Packages added to EPEL should be maintained long term. I did the builds for EPEL 8 and 9, and I don't think it's a good idea to add it to EPEL 10 because it will give users the impression that it will be maintained through 2035 (the RHEL 10 EOL date). It's already bad enough that we'll likely be maintaining it through 2032 (the RHEL 9 EOL date), and I'm not interested in extending that pain. I may even retire the package from EPEL early if any unsolvable security issues are discovered in the meantime. https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_security_reasons In Fedora, I think we should deprecate the package now, and make a plan for the eventual retirement. https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/
(In reply to Carl George 🤠 from comment #5) > > Well that's drastic! > > It's really not. The last commit upstream was in 2020, and the last tag was > in 2018. Currently there are 439 open issues and 123 open pull requests. > The pull request to add PCRE2 support was opened in 2016, never got a > response from the maintainer, and was closed by the submitter in 2018. > Shlomi was able to add PCRE2 support by borrowing the Debian patch (which > itself is based on that closed upstream PR), but that's not a very > sustainable approach for what appears to be a completely inactive project. > > Packages added to EPEL should be maintained long term. I did the builds for > EPEL 8 and 9, and I don't think it's a good idea to add it to EPEL 10 > because it will give users the impression that it will be maintained through > 2035 (the RHEL 10 EOL date). It's already bad enough that we'll likely be > maintaining it through 2032 (the RHEL 9 EOL date), and I'm not interested in > extending that pain. I may even retire the package from EPEL early if any > unsolvable security issues are discovered in the meantime. > Reading Carl's message, I tend to agree that fedora's ag package should be discontinued. Also note https://beyondgrep.com/more-tools/ and especially ack and ripgrep.