Re: [arch-dev-public] Upcoming PHP 8.1 update
On 2022-01-21 17:51:17 (+0100), Pierre Schmitz via arch-dev-public wrote: > I just released PHP 8.1 into [extra]. > > Please also check https://archlinux.org/todo/php-7-retiredment/ so PHP > 7 can be dropped soon. > > have a nice weekend, Unfortunately, it likely won't be ;_; https://bugs.archlinux.org/task/73452 Another reminder for users to *please* join the Testing Team [1] and help test our packages! Best, David [1] https://wiki.archlinux.org/title/Arch_Testing_Team -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Upcoming PHP 8.1 update
Hi On Sat, Jan 22, 2022 at 5:00 AM David Runge via arch-dev-public < arch-dev-public@lists.archlinux.org> wrote: > On 2022-01-21 17:51:17 (+0100), Pierre Schmitz via arch-dev-public wrote: > > I just released PHP 8.1 into [extra]. > > > > Please also check https://archlinux.org/todo/php-7-retiredment/ so PHP > > 7 can be dropped soon. > > > > have a nice weekend, > > Unfortunately, it likely won't be ;_; > > https://bugs.archlinux.org/task/73452 And there is another php8.1 bugreport https://bugs.archlinux.org/task/73451 > > > Another reminder for users to *please* join the Testing Team [1] and > help test our packages! > > Best, > David > > [1] https://wiki.archlinux.org/title/Arch_Testing_Team > > -- > https://sleepmap.de >
Re: [arch-dev-public] Upcoming PHP 8.1 update
Hi David, 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. 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. 2) Keep trying to patch upstream packages to keep them working. 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. 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. *) https://www.php.net/supported-versions.php On Sat, Jan 22, 2022 at 10:57 AM David Runge wrote: > > On 2022-01-21 17:51:17 (+0100), Pierre Schmitz via arch-dev-public wrote: > > I just released PHP 8.1 into [extra]. > > > > Please also check https://archlinux.org/todo/php-7-retiredment/ so PHP > > 7 can be dropped soon. > > > > have a nice weekend, > > Unfortunately, it likely won't be ;_; > > https://bugs.archlinux.org/task/73452 > > Another reminder for users to *please* join the Testing Team [1] and > help test our packages! > > Best, > David > > [1] https://wiki.archlinux.org/title/Arch_Testing_Team > > -- > https://sleepmap.de -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Upcoming PHP 8.1 update
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 signature.asc Description: PGP signature
Re: [arch-dev-public] Upcoming PHP 8.1 update
On Sat, Jan 22, 2022 at 9:45 PM David Runge 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 i
