On Wed, Aug 24, 2022 at 05:14:33AM +0200, Kevin Kofler via devel wrote: > Ben Cotton wrote: > > == Summary == > > Upstream stopped the support for the old 'pcre' package. It only > > supports the new 'pcre2' version, so Fedora should deprecate it so it > > could later be retired and removed from Fedora entirely. > > > > == Owner == > > * Name: [[User:ljavorsk| Lukas Javorsky]] > > * Email: ljavorsk@xxxxxxxxxx > > This is simply a non-starter. "non-starter" is not the phrase you are looking for. This change is explicitly about *deprecating* the package to encourage packagers to move off the dependency and not add any new dependencies. This is something that we certain *can do*, and something that'll benefit the distro. What we do with the package two years down the road when as many dependencies as possible have been removed, is a separate topic, subject to the (at this point hypothetical) second Change proposal. So… hold your guns unless you have issues with *this* part, i.e. deprecation. > You yourself list dozens of packages using this compatibility library. Some > of those are themselves compatibility libraries (e.g., kdelibs 3 and 4) and > will never be fixed by upstream. It is entirely impractical to port them to > a completely different API. But even current leaf packages such as rkward > are in the list. > > PCRE 1 needs to remain as a fully supported compatibility library for the > foreseeable future. > > > == Detailed Description == > > Upstream stopped supporting the old 'pcre' package. The 8.45 is marked > > as a final release and nothing else will be added/fixed in it. This > > may lead to some unresolved CVEs, which would have to be resolved by > > the maintainers. Unfortunately, due to our limited capacity, we > > wouldn't have the time and experience to solve this by ourselves, so > > we need to deprecate this package. After the deprecation is done, the > > very next step would be starting the [[PcreRetirement|retirement > > change]], so the package is removed from Fedora entirely. > > How different is the code from the pcre2 code? If it is completely > different, then CVEs found in pcre2 will typically not affect the legacy > code, and you can expect a steep drop in found CVEs with the upstream drop > of support. If, on the other hand, it is sufficiently similar for the CVEs > to apply, then the fixes can also be backported. > > In the end, my suggestion if you are unable to deal with the security > vulnerabilities is to simply orphan the library and let someone else pick it > up. (If nobody else does, I will, because at least 3 of my packages depend > on it.) That is always an option. I think the porting effort depends a lot on what parts of the pcre api are used. So let's figure out first what can be ported, and of the things that can't, what can be dropped. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
