Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105016
MIME-Version: 1.0
References: <e91aa5a7-5cb6-290f-410e-3eb5c2f0b37f@gmail.com>
 <c9e6fe5a-6b93-cc55-5bd6-4f4a94b64340@fedoraproject.org> <19efc114-32c4-e02b-76b1-480bf36b336c@gmail.com>
In-Reply-To: <19efc114-32c4-e02b-76b1-480bf36b336c@gmail.com>
Date: Fri, 29 Mar 2019 16:41:57 -0600
Message-ID: <CAFMT4NqcsjY3gPHC7Zh9oALQertQDvXoLoSD1UN5hc05OJ5gyA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Remi Collet <remi@fedoraproject.org>, internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Updating bundled libs (specifially, oniguruma) on 7.1/7.2
From: levim@php.net (Levi Morrison)

On Fri, Mar 29, 2019 at 2:17 PM Stanislav Malyshev <smalyshev@gmail.com> wrote:
>
> Hi!
>
> > 7.1 have version 5.9.6
> > 7.2 have version 6.3.0
> > 7.3 have version 6.9.0 (latest is 6.9.1)
> > 7.4 only use system library
> >
> > As we encourage system library usage (default in 7.4), and if this raise
> > the minimal allowed version, this will create issue for 7.4
> >
> > Ex
> >       RHEL have 5.9
> >       Debian have 6.1
>
> Any reason why those are so far behind? 5.9 is from 2014!

Yes: Red Hat Enterprise Linux is intended to be *incredibly* stable.
It comes at the cost of always being a bit old.

> > I think we have to manage such change in a compatible way.
> > (feature availability tested in configure
>
> This creates a very bad situation, where we can not implement security
> improvements because we have to be compatible with a version of the
> library that has been released 4.5 years ago.

In many cases, Red Hat will backport security fixes to the old software.

> Is there any reason why we prefer system library if actual system
> library is not being properly maintained by packagers? I think if most
> packagers neglect to keep with latest versions so much, we should keep
> bundling it - otherwise, we are just exposing our users to security
> issues and give them slower and buggier and feature-impaired library
> despite being completely able to do better.

A lot of software will bundle unusual dependencies, and then have an
option to build using a given path, or to use the bundled extension. I
assume that's what we are doing with libonig? The person doing the
build should have the power to choose here.

> > P.S. from downstream PoV, as soname is different is it possible to have
> > compat package for library (v5.9 uses 2, v6.1 uses 4, v6.9 uses 5)
>
> Not sure what you mean here, could you explain?

I think Remi means that the .so files are versioned, so you end up
with libonig.so.2, libonig.so.4, and so on. Or alternatively they may
be named libonig2.so, libonig4.so, and so on. Either way, they can
coexist in the same library directory.