[arch-dev-public] Upcoming PHP 8.1 update

[David Runge]

Hi Pierre,

On 2022-01-22 20:45:45 (+0100), Pierre Schmitz via arch-dev-public wrote:
> sorry about the hassle. I did not expect much issues here. I would
> consider this one of the smoother PHP updates. Unless people ignored
> warnings by previous PHP versions. I guess that is what mostly happend
> here. PHP 8 gets more and more strict each version.

So far there has been no further reaction on the ticket, so I hope there
is not much more breakage. :)

Some transitions take a bit of time.

> After reading the issues on Nextcloud's Github repository I guess we
> can conclude that they will probably lack behind at least one PHP
> minor version. This is quite incompatible with the Arch way.
> 
> Anyway, let's talk about some options to solve such issues:
> 
> 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?

> 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.

> 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.

> 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?
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.

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.

Best,
David

-- 
https://sleepmap.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20220122/c8495f30/attachment.sig>