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@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 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@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue