Thank you for all of your feedback. As Zbyszek mentioned, this change is only about the *deprecation*, not the *retirement*. This means that if the pcre is deprecated, no new package will be allowed to require it. Also, it would mean that all of the existing packages will be notified about this deprecation and will be encouraged to port to the new pcre2 library.
However, if some package has a solid justification for not porting to the new pcre2 package, it is fine. In the event that this deprecation is approved, the next step will determine whether the package will be retired completely or orphaned and supported by some maintainers. Anyway, the main idea behind this change is to prevent any new packages coming to Fedora 38 to require the old pcre package and forward them to use the newer version of it *pcre2*. Lukas On Wed, Aug 24, 2022 at 9:38 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > 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: ljavo...@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-le...@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 > -- S pozdravom/ Best regards Lukáš Javorský Software Engineer, Core service - Databases Red Hat <https://www.redhat.com> Purkyňova 115 (TPB-C) 612 00 Brno - Královo Pole ljavo...@redhat.com <https://www.redhat.com>
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
