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(a)redhat.com
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
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
> == 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
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.