There is currently an open issue: Support php8.1. TL;DR: people are working on it. But it’s not expected to be resolved until next release in March.
So, for people who are hit with an OS that has transitioned away from earlier php versions and now are on php8.1 with their Nextcloud instance broken, I created this topic. This way the issue stays clean(er), hopefully. Please add your distro’s solution to run php7.4 or php8.0 again next or instead of php8.1.
I’ll start for Debian (edit: testing (bookworm)) people, with php-common version 76 both php7.4 and php8.0 can be installed on your system:
But the latest Debian (Bullseye 11) default is PHP7.4!
This was one of my biggest gripes back when I used to use Debian (1998-2004), everything is SO out of date, and it’s difficult to run modern software without breaking things. What version of Debian is currently running PHP8.1? A quick websearch shows the previous PHP8.0 listed as “unstable”.
This even carries over to Raspbian/Raspberry Pi OS, where getting current functionality is difficult because the libraries are so old, not because they’re so new.
You should be showing Debian users how to install PHP8.0, so their Nextcloud instance has current features!
I never said otherwise. But the 40 year old HP-UX is still getting security patches and is running rock solid, and that’s about as relevant. You’re coming off rather butthurt about running old software!
Why did you put “latest shit” in quotes, when I didn’t say that?
What I said was “it’s difficult to run modern software [on Debian] without breaking things”, which it is. If I want a reliable, stable system, I want to be able to run stable software in 2022, not the stable software from 2019 (which is what php7.4 is).
Nextcloud itself recommends PHP8.0, because all new features have only been been written for PHP8.0 since Nextcloud Hub v22. If you want to take advantage of ALL Nextcloud features, you need PHP8.0. If you want SOME features, you’ll use PHP7.4.
I’m sorry this makes you angry, but there’s a difference between stability/reliability, and defaulting to obsolete libraries multiple versions out of date.
Yes, yes, sorry. But swindhab misquoted me and put words in my mouth. They passively-aggressively attacked me, so they had it coming.
The title is not correct, unless you are talking about Arch or other rolling releases distros. But Debian is not a rolling release distro and the testing repo is, as the name might suggest, not meant to be used in production. Except you want to make your life unnecessarily difficult.
The better way, If you want to use newer PHP versions in Debian, is to do it the other way around. Instead of using Debian testing, use stable and then install newer versions of PHP from the Debian backports repo. Or you could use the third party repos maintained by Ondřej Surý. He is also the official maintainer of the PHP packages in Debian.
I am talking about distro’s that are getting php 8.1 in their repo’s. I do not care if they are rolling releases distro’s or not. Neither what Debian is or not.
Testing may not be meant to be used in a production environment, but that doesn’t mean people use it. I didn’t start this topic to talk about distro’s and what they are meant for.
I choose to run testing on my own environments and have done so for a long time. If that means I need to figure things out sometimes, I’m fine with that. It also means I can share my experiences when I think it may help others.
Name one which is not a rolling release. Debian has it only in testing / sid / and backports. Ubuntu LTS has it only in the upcoming 22.04 LTS release. Don’t know about RHEL and it’s derivates, but I doubt that the already have it in their stable repos.
Yeah people do all kind of things, but that doesn’t necessary mean that Nextcloud can and should support all of it. Nextcloud does support the PHP versions, that are in the current stable / LTS releases of the most popular distros like Debian, Ubuntu, RHEL etc, which makes sense imho. And it definitely makes more sense to use such a distro as a base, and then maybe install newer versions of a few selected packages on it, instead of using a bleeding edge distro and then somehow trying to get the thing under control with apt mark, apt hold and similar shenanigans.
Yeah that’s fine. But it’s not the way anybody should do it on a production server. And yes all these OSs will eventually transistion to newer PHP versions on their next LTS / stable releases, and I’m sure Nextcloud will be supporting PHP 8.1. by then
Look, I get that you are trying to be helpful. But in fairness, it costed me a lot of energy and it made me want to leave the forum. So, I’m not going into all the arguments you wrote, that was not what I came here for.
Ubuntu 20.04 LTS’ php 7.4 does not include php-smbclient, which rather forces us to use Ondřej Surý’s repos if we’re supporting SMB external files, which leads to the current version of everything moving to (now) php8.1. It’s great that Nextcloud “recommends” php 8.0, but every time I’ve tried to switch Nextcoud over to php 8.0, I get errors with LDAP authentication that no developers seem to want to acknowledge exist.
Alltough I had one issue on my Debian 11 test server, with Ondřej Surý’s repos. About two weeks ago, apt suddenly wanted to install some PHP 8.1 packages. I don’t know what exactly went wrong. I ended up uninstalling PHP and installing 8.0 again, and since then I have had no issues including an upgrade to 8.0.15 this week.
I do not think that so many people are hit. I am not hit and I am certainly not missing it.
You wrote a short tutorial for debian users who are not hit how to update their systems to testing and/or using a newer php version to be hit.
Ok, you can do that.
As a debian user who does not want testing/unstable/figure things out in production. I am patiently waiting until testing goes into stable, like every companies best practice. And that is the time php7.4 can be dropped. New cannot have the experience of a long time by definition.
Yes I’m pretty sure I did it that way. Anyways. I just wanted to make this point clear, in case some newbie reads this.
Btw. The hole premise of this thread is wrong imho. Beginning with the title and the OP giving instructions on how not to do things, in order to workaround an issue, that wouldn’t exist in the first place, if things had been approached the right way from the start.
I use Arch on my desktop and unlike Debian, it is designed to be used as a rolling release. Still, I would never use it to run server applications like Nextcloud and I would not recommend it to anyone for that purpose. But if people, for whatever reason, absolutely want to use Arch or even Debian testing on their servers and they know what they are doing, sure why not. I wont stop them.
But I also think that some people wouldn’t use Debian Testing or Arch on a server in the first place, if they really knew what they were doing. Especially Debian Testing is often used, because people want to get newer package versions than Debian stable offers, and them not knowing how to use the Backports repository, which in most cases would have been the better choice.