[arch-dev-public] Upcoming PHP 8.1 update

[Pierre Schmitz]

Hi Kristian,

I would not recommend to deploy PHP 7 after its end of life in
November this year. In theory someone might be able to backport
security fixes though.

In this case I would urge to update Flyspray to its latest version
which has support for PHP 8.0:
https://github.com/Flyspray/flyspray/releases We seem to use version
0.9.9.7 which we updated 9 years ago. From there on its probably
easier to make to work with recent PHP versions.

Greetings,

Pierre

On Sun, Jan 23, 2022 at 3:15 PM Kristian Klausen <kristian at klausen.dk> wrote:
>
> On Sat, Jan 22, 2022 at 20:45:45 +0100, Pierre Schmitz via arch-dev-public wrote:
> > 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.
>
> FYI:
> As stated earlier by Jelle[1], our bugtracker isn't currently compatible
> with PHP8. In case PHP7 is dropped from the repos and no one steps up
> fixing the flyspray code[1]. The DevOps team will likely just run the
> the bugtracker in a container of some sort.
>
> [1] https://lists.archlinux.org/pipermail/arch-dev-public/2021-December/030571.html
> [2] https://gitlab.archlinux.org/archlinux/flyspray/
>
> - Kristian
>
> > 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 <dave at sleepmap.de> 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



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