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