[arch-dev-public] Upcoming PHP 8.1 update

[Pierre Schmitz]

On Sat, Jan 22, 2022 at 9:45 PM David Runge <dave at sleepmap.de> wrote:
> On 2022-01-22 20:45:45 (+0100), Pierre Schmitz via arch-dev-public wrote:
> ...
> > 1) Let's no longer package software that requires older versions of
> > PHP. Personally I would run such complex software with very specific
> > needs in a Docker container. E.g. Nextcloud even provides an official
> > one.
>
> This means giving up on system packaging and I do not agree with the
> mentality of hiding away all legacy in a container.
> That's neither beneficial for us nor for the upstream projects or for
> the diversity (in regards to how to use and run a piece of software) of
> the ecosystem in general.
>
> This also means that running and installing this software in an Arch
> Linux based container would be not supported and/or flaky as well, which
> I consider a detriment to the distribution :-/
> To spin this wheel a bit further: What is the point of having a php
> package, if it could also be provided by an upstream container?

I saw this more as an option for rare exceptions and not the default.
This is great if you cannot run your software at all otherwise. This
is also not a real option as users can do this today already. :-)

> > 2) Keep trying to patch upstream packages to keep them working.
>
> That's what we usually do and that is also what keeps momentum in
> certain upstream projects.
>
> FWIW, that's what we do for the entire python ecosystem for better or
> worse and more specifically for e.g. python-django, which has a few
> dependents that can not easily be upgraded from one minor version to the
> next.
>
> This sometimes means getting involved with upstreams, providing patches,
> using patches, etc. which is part of the packager role that we are in.
>
> However, the problem we are currently facing is that of upstream
> frameworks and languages being unable to provide sufficient
> compatibility guarantees.
>
> For this we need to make a greater effort to have testers and more
> clearly defined (automated) test scenarios. If we can not make this
> effort to some (even small) extent, I'm wondering why we are packaging
> languages at all anymore.

I agree this should be the way to go. Not sure if I get your right
here, but (extensive) testing is best done by upstream projects
though. And a lot of them even test with release candidates so their
releases even work on day one. I usually provide release candidates
for Arch's PHP packages as well. I could make that more public for
maintainers that want to test as early as possible. We might also ask
packagers to run basic unit tests during packaging.

> > 3) We provide two sets of PHP packages: "php" would always be the
> > latest stable version and be released no matter what. In addition to
> > this there would be e.g. "php-legacy" packages providing the oldest
> > supported version, currently 7.4. This would be updated to 8.0 in
> > November when 7 is EOL and php-8.2 get's released. The difference to
> > the currently available php7 package will be the lack of a version
> > number in package and binary names. So both packages will be a moving
> > target, but always two versions apart.
>
> Wouldn't this mean that those php versions are mutually exclusive?
> I would be more in favor of moving towards a unified php version again,
> else we might end up with a lua or java situation eventually.

They would be installable and usable at the same time. In the same we
as you may currently use PHP 7 and 8, which was originally meant to be
a temporary solution. There is a catch though: The user has to alter
the configuration when he wants to switch versions.

> > I would give option 3 a try. I'd like to get rid of versioned
> > constraints then and reduce the amount of third party modules. While
> > we would end up with more packages we need less testing and will be
> > able to move faster.
>
> I don't think the option to "move faster" is a good one if there is
> nothing that is outright compatible anymore ;-)
> What would be the target of an up-to-date php, that has no packages
> using it?

This is likely exaggerated. Adaption of new versions is quite fast
these days, especially minor ones. Most of the frameworks, packages
and libraries had compatible release before the first patch release.
But of course this heavily depends on what you work with. And here is
the whole point of the issue: On one hand people want or need the
latest packages and on the other hand some projects might need more
time.

> With a two version system (that is mutually exclusive?) we would have
> the same issues with incompatible projects as soon as we move from one
> version to the other, just at a different point in time.

This might be true and as we have some packages with dead upstream
projects this is even likely. The only option would be to remove such
packages from our repositories then. I wouldn't want to provide PHP
packages that do not receive any upstream security fixes anymore. This
might sound harsher as it actually is as this would mean packages did
not manage to work with PHP versions released two years ago.

> We have version constraints to guard against these major/minor version
> upgrade scenarios and to be able to have an overview as to what is not
> yet compatible and then act based on that information in a testing
> environment.
> I do not believe abolishing that just so that we can upgrade and break
> everything without even knowing about it makes a lot of sense, but maybe
> I did not understand your intentions correctly.

I would hope this would break less as we would depend such packages to
PHP versions that are actually supported by the upstream projects. As
an example: As we now know that Nextcloud usually needs some more time
we would suggest to install php-legacy. Packages like WordPress or
phpMyAdmin could depend on the latest php packages as these are
usually compatible.

Greetings,

Pierre

-- 
Pierre Schmitz, https://pierre-schmitz.com