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.
What “went wrong” is that the current version of php moved to 8.1, as I said, so you had to install the specific version 8.0 packages. I never said that couldn’t be done.
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.
as long as you still get security updates for the PHP version you’re using and Nextcloud still supports the corresponding PHP version everything is fine.
Nobody forces you to upgrade immediately just because a new Ubuntu version is out.
…but If you want to upgrade Ubuntu now, you can, because Nextcloud 24 does support PHP 8.1
If you don’t want to upgrade Ubuntu just yet, you don’t have to, because Nextcloud 24 still supports PHP7.4.
If you don’t want to upgrade to Nextcloud 24 just yet, stay on Ubuntu 20.04 for the time beeing.
There is always the possibility to install a specific PHP version manually https://deb.sury.org/
As a system admin with a manual installation of Nextcloud, it is your responsibility to check which PHP versions your OS provides and whether your Nextcloud version does support it. Based on this information you can then decide in which order you need to upgrade the OS and the application.
Nextcloud usually supports at least 2-3 PHP versions and with Ubuntu LTS you theoretically only need to upgrade every 4-5 years. So it is more or less guaranteed that there is at least one supported Ubuntu version at any given time that ships a PHP version that is compatible with a Nextcloud version that is still supported. If you don’t want to keep track of such things, I would recommend using an appliance like Nextcloud AIO.
For you nextcloud might be the center of the world and everything revolves around it. So you choose a system to acommodate nextcloud.
That’s not the case here.
I have a system running and nextcloud has to work on it as every other software does.
BTW: From a software deployment point of view, nextcloud is a nightmare:
I upgraded the system and nextcloud stopped working: php was too new.
I trie to upgrade nextcloud to version 24 but that was not possible because neither web nor occ nor updater.phar worked, because: php was too new. There seems to be no way to migrate the database and the data to a newer installation.
In the end I had to backport php 7.4 to debian testing to „rescue“ nextcloud.
Sorry to say, but from a software deployment point of view upgrading a system without checking if all software components are compatible is a nightmare. That’s really not the fault of nextcloud.
You intentionally and explicitly upgraded it with the sudo do-release-upgrade -d. command. The -d option stands for --devel-release and without this option, it it wouldn’t have offerd you an upgrade to 22.04 just yet, because Ubuntu only actively offers a new LTS release after their first point release. Why do you force a release upgrade, if you don’t really want to deal with the implications?
If you hadn’t actually bothered with it and just kept your system up to date regularly by using apt update && apt-dist-upgrade, while updating Nextcloud whenever it offered you a new update, this wouldn’t have happened to you. And at the time when Ubuntu offerd you the release upgrade, everything would have worked, because by then you would have already had Nextcloud 24 installed.
Besides the fact, that update-notification does not work at all in nextcloud¹, that’s not the point.
Yes, I could have avoided the problem if I had updated nextcloud prior to the system-update, but the problem is, that nextcloud can get you quite easily into a situation, where there is practically no way to rescue your data.
No, you could have avoided the problem by checking what the system-update does and checking all software you rely on for compatibility. If there are compatibility issues you can either postpone the system update or check if there are ways to resolve those compatibility issues, eg with an update.
If you upgrade your internet connection from cable to fiber you would also check first if your current router/modem/whatever is able to use the new connection or if you need to buy something different, wouldn’t you? You can’t blame your old router for not supporting the new connection.
But nevertheless, I’m glad you resolved the problem and have again a working nextcloud installation.
I’m repeating myself, but this is exactly why there are appliances like the Snap Package or Nextcloud AIO that are based on container technologies. They come with all the dependencies preconfigured in containers, so you don’t have to worry about them as an end user. But if you decide to install and configure all the components yourself, you also have to maintain them yourself afterwards. Nextcloud is of course not perfect and there is always room for improvement but in this specific case there is not much the Nextcloud developers could have done to avoid this.
