nextcloud 12.0.4 incompatible with php 7.2

[dvzrv]

Arch Linux, as a rolling release distribution, follows upstream closely, which is why php 7.2 has been adopted a few hours ago. This renders nextcloud (server) unusable for new installations of Arch Linux, while longer running installations theoretically still have the possibility to downgrade or not upgrade.

This is quite unfortunate, given the fact, that this is a feature release for php.

I'm aware of #6786, but I'd like to have an open bug for this, as this happened before with owncloud server and it would be nice to circumvent situations such as these in the future.

Steps to reproduce

1. Install nextcloud on Arch Linux

Expected behaviour

Should work.

Actual behaviour

Is not compatible with php 7.2

Server configuration

Operating system: Arch Linux

Web server: Any

Database: Any

PHP version: 7.2

Nextcloud version: 12.0.4

Updated from an older Nextcloud/ownCloud or fresh install: Any

Where did you install Nextcloud from: Arch [community] repository

[Schmuuu]

I nearly ran into the same problem. 45 minutes before my automatic update I checked what updates would come and saw PHP 7.2. I instantly stopped my automatic updates.

Nextcloud 13 seems to support 7.2: https://github.com/nextcloud/server/blob/185b6235bf755b8fd519c2a59ed72f8549658cb5/index.php#L36

and it should be released pretty soon, as it is already in Beta state.

[rullzer]

Yes unfortunately the changes in php are not minor to make nextcloud 12 7.2 compatible.

indeed NC 13 will be compatible with php 7.2.

[alerque]

Compatibility with the current released version of the language should be top priority and released as soon as possible in a point release! Please don't put this off until the next feature release, my boxes have just all gotten borked and I'm forced to evaluate which other released software I can safely downgrade to get Nextcloud back.

Yes another release cycle is work, but it looks like 13 has huge feature set changes coming and might be held up testing for a while. PHP 7.2 compatibility should be ported to a 12.0.5 or 12.1 released ASAP.

[dvzrv]

@MorrisJobke I also don't get why you are closing this bug. It is an ongoing problem now.

[Natanji]

I'm a bit stunned that you @MorrisJobke apparently are fine with Nextcloud 12 only working on systems that have not yet been updated to PHP 7.2, and just close this. This is a bug. Your software does not work with the most up to date version of PHP 7, despite you recommending PHP 7. In the coming weeks, many more systems will be updated. In the case of up to date distributions like Arch Linux, you effectively give users the option to completely uninstall Nextcloud or to not be able to update any of their packages anymore, including critical security patches. Please realize what situation you put users in.

What are the concrete things that even prevent this compatibility? The list of list of backward incompatible changes doesn't look like something that a lot would have to be rewritten for, only local code changes would have to be made - at least, unless you needed rand() or mt_rand() to return the same sequences for a given seed as before, even after the update to 7.2. Which sounds quite unlikely.

I understand the team is focussing on getting Nextcloud 13 out ASAP, but being willing to outright break your software - without even warning admins in advance! - just because you for some reason want to drop Nextcloud 12 like a hot potatoe after Nextcloud 13 is released? This is not the kind of behaviour one should expect from people who aim to have a stable cloud hosting solution.

[paroj]

there is still the php70 package :wink: Also this is exactly what "backwards incompatible change" means. Therefore you only should install the un-versioned php package, if you know what you are doing..

[divinity76]

the 7.2 issues are all mcrypt related, right?

while it is true that mcrypt was removed from php-core, it is still available as a pecl extension, with 7.2 (and git master) support, see https://pecl.php.net/package/mcrypt

... that said, whatever mcrypt features you're using should have been ported to OpenSSL a long time ago.

[CountMurphy]

@MorrisJobke So when exactly is 13 getting released? I cannot run any updates on my server unless I remove nextcloud. If 13 isn't ready, any chance you could just patch NC 12 to run with the current php package? This is a huge breaking issue

[divinity76]

@CountMurphy pretty sure all you have to do is install mcrypt, see above (i can't actually test it now though)

[Schmuuu]

Hi,

As mentioned above, I'm affected as well by this problem. However I do understand the developers. There are new futures to develop, bugs to fix and now adapting the whole code to changes of certain tools (apache/ nginx, php, ...) is very time consuming. I also understand that there are list of supported software versions for a reason. As far as I know Arch Linux is not even a supported OS - very likely because it is a rolling release and this are the problems that happen then. My impression is, that the developers are anything but lazy and that they do everything they can to have a good mix of release-cycles, new features, support of older releases and there are many backports of bug fixes.

Okay, looking for solutions... What I can suggest is to simply exclude php updates from your regular system updates. I added the following lines to /etc/pacman.conf:

IgnorePkg   =php
IgnorePkg   =php-fpm
IgnorePkg   =php-gd
IgnorePkg   =php-intl

While I am not very sure about the packages php-apcu (would be updated to php-apcu-5.1.8-2) and php-memcache (would be updated to php-memcache-3.0.8-6) and their dependencies, I excluded them as well:

IgnorePkg   =php-apcu
IgnorePkg   =php-memcache

No I can run my daily updates without any worries again. So the main problem with security updates is solved. (Sure if PHP is already updated, it's a bad situation and a downgrade is necessary first) Starting with Nextcloud 13 I will comment these entries again.

Hope it helps to relax the situation a little bit.

[Natanji]

@Schmuuu That doesn't actually work and your setup will most probably stop working after a reboot. This is because php and associated packages depend on libraries that are also used elsewhere in the system. Some libraries have received updates in the meantime, which means their Sonames have changed (as they must). The php 7.1 package is still linked against the older versions of the libraries, not the newer ones.

The only reason your setup works at the moment is probably because the old .so files are still loaded by your system. I expect your system to break upon next boot; for me it did at least, and I had to manually downgrade some libraries (and their dependencies... and their dependencies... etc.) to get it working, for instance the icu package. And this downgrade might well break other software now (just haven't noticed it yet), because of course all other software in Arch that depends on the same libraries is now linked against the newer version of said libraries, which it won't be able to find unless I update them (wherupon php will break again). Of course, this situation is only going to get worse over time as more libraries that the old php version depends on are updated. Rolling release distros cannot really support partial updates of your system, and Arch is no exception.

So no, I don't find this relaxing at all. Even if Arch is not an officially supported distribution (and thus Nextcloud can't be expected to do any code changes in advance to fix this limitation - I agree there), at least communicating a known breaking change in advance to package maintainers is something that should be expected in the Open Source world!

If this change was communicated downstream, it would be easy to write "yup folks, we knew this limitation, we DID communicate this, but your distro didn't bother. You broke it, you have to fix it". Since this was just closed without comment instead, this seems to me like they did not communicate this dependence on php<7.2 despite knowledge of the problem and ample time to do so. This means they are at fault for breaking this, and as such they should fix it.

Yes, this means much more work now - which could have been easily prevented by warning distributions/package maintainers...

[steadybright]

I'm faced with the same situation @Natanji described (reverted to several previous PHP releases (php, php-gd, etc., but that did not ressurect Nextcloud).

I'm considering uninstalling Nextcloud so that I can update my Arch system.

Does anyone know if uninstalling Nextcloud will remove all my settings/customizations (calendars, etc.)?

What a mess... but I suppose I'm getting what I paid for.

[eli-schwartz]

Is there a particular reason that backporting the php72 fixes to some nextcloud 12.0.5 maintenance release is not feasible? Failing that, can the specific backports (including modifications) needed for nextcloud 12.0.4 be identified in order to apply the backport downstream as an interim measure? I ask because from the sound of things, backporting those fixes is non-trivial without pulling in lots of nextcloud 13 changes.

@paroj Arch Linux does not provide old versions of software in parallel to current versions, therefore there is no php70 package. In theory, the nextcloud maintainer could provide a php71 package just for nextcloud 12, but that might be issueful with the main php package, and also sort of defeats the purpose of having up-to-date software to begin with. (We do not package php 7.2 just for the fun of it, new versions tend to fix broken things and contain security fixes in addition to adding new features....) This is in addition to of course being rather messy.

[paroj]

php7.2 is clearly marked as backwards incompatible, so you can not just upgrade and expect depending stuff to work. Furthermore as you can see here PHP has always two supported releases in parallel. So currently php7.1 is still up to date software. If arch does not properly reflect this, it is an issue with arch really.

@eli-schwartz a quick search on google gave me the arch wiki page on PHP which mentions AUR for older versions. Probably for situations like this. Going there I find: https://aur.archlinux.org/packages/php70/

seems like the arch users here are much better at crying then at using google.

[CountMurphy]

Aur packages aren't official. I think thats what eli meant when he said Arch Linux does not provide old versions of software.

[eli-schwartz]

@CountMurphy It most certainly was what I meant.

@paroj I daresay I know that quite well.

But anyway, according to that blanket logic php5.6 is also supported... Arch Linux updates to the latest version of current, stable software and does not provide old-but-still-supported software as a general rule. Nextcloud is nowhere near the only php based package in our repos, not to mention the fact that the AUR etc. runs on php... we value using the latest stable release of php when deploying our own infrastructure more than we value staying on older versions for the sake of one package in our repos.

If the official upstream response to this incident is "use an AUR package", then that means nextcloud depends on an AUR package... and we cannot have repository packages that depend on AUR packages. Sure, users can get both php70 and nextcloud from the AUR, but wouldn't it be nice if we didn't have to delete nextcloud from the repos

[Natanji]

@paroj: Just because the previous version is still supported (aka receiving security patches) by PHP, doesn't mean it is up to date. Of course you are right that one cannot upgrade and just expect things to work; but it's completely unrealistic for the php maintainer to check if every single package that depends on php still works after the update. This is why in the FOSS world, if upstream knows that their software will break with an up to date version, they will notify maintainers in advance. It's a tried concept and if you want to be taken seriously as a FOSS developer, as I'd hope Nextcloud GmbH wants to be, then you need to communicate this. There really is no other realistic way.

What I will agree with you about is that php7.1 will still be officially supported for another year, meaning that Arch getting a php71 package to fix this problem is an option. (Having a package that is no longer supported by the developers in the official repositories would not be one I think, especially for internet-exposed services that need security updates). I have proposed that the maintainer in Arch does this. I'd still much rather like Nextcloud to fix this upstream, since PHP 7.2 will eventually hit other distributions.

[saper]

Come on, PHP 7.2 is six days old at the time as I write this!

[Natanji]

@saper: The release is, yes - the last beta (of which there were 3!) was available in August. So there was a total of FOUR MONTHS in which this could have been fixed. Despite this, people already noticed this bug in early October as by #6786. This proves that Nextcloud developers were 100% aware of this bug TWO MONTHS AGO and did... precisely nothing about it. Like, no reaction at all, not even warning anyone. Just closing the bug and acting like there's nothing to do.

[saper]

@Natanji this is not NextCloud's fault if they decide to not to rush to fix this in the minor release, especially given the fix is non trivial. The moving part here is PHP, not Nextcloud. Nextcloud DID NOT change when you have updated your server. PHP did.

If you really really want to blame someone, please talk to the PHP package maintainer of your system who might need some help in figuring out regression testing with other packages.

I've seen other apps break when the engine updates (MediaWiki on most major PHP updates, binary node modules like https://github.com/sass/node-sass breaking with almost every nodejs update) and it is unreasonable for maintainer to provide compatibility with the latest and greatest on the first day. It is system's administrator ultimate responsibility to check if the system is ready to move from important engine version A to version B.

[edit] link to the over-the-top reaction on mastodon removed

[paroj]

But anyway, according to that blanket logic php5.6 is also supported

yes, e.g. phpbb gained php7 support this year (1 year after php7 release). If you look around a little it, you will actually find many php based applications with compatibility issues. (e.g Drupal, Tiki)

Nextcloud is nowhere near the only php based package in our repos

probably just the only one you have tested with the new release so far..

we value using the latest stable release of php when deploying our own infrastructure

you should note somewhere that the provided php stack only supports running your own infrastructure. Then this discussion would be resolved as well :wink:

[LukasReschke]

Tell me how that isn't completely stupid and unprofessional?

I’d like to remind everyone of our code of conduct. There’s no need to use such words.

[MorrisJobke]

Hey @Natanji ,

just some words from me as well. I read the rant at https://octodon.social/@natanji/99123165202381895 (thanks @saper)

Regarding the problems:

1) closing without comment:

I closed this, because it was communicated by @rullzer that 12.0.x is a minor release and we never supported never PHP in released versions (only in the next major release)

Yes unfortunately the changes in php are not minor to make nextcloud 12 7.2 compatible.

indeed NC 13 will be compatible with php 7.2.

2) blaming us, that we didn't test against the beta

We did, that's the reason, why master has tests with PHP 7.2 running: for example https://github.com/nextcloud/server/blob/cb951b42b238cc90d6382547903bb4e8f6b5601e/.drone.yml#L703-L705

3) upstream does not report to downstream

I guess it is a bit too much, to go to every single distribution out there and tell them, with what we are compatible.

4) upgrading a key part of the stack to a new major version and complaining to the upstream project, that your production server is now broken

As we documented everywhere: please test, have backups and in the worst case roll back to the backup. Sorry to say this and this sounds maybe a bit arrogant (which it shouldn't), but if you run something in production you should maybe test it before complaining and if you run something like Arch Linux you should know what you do - otherwise use Ubuntu or another distribution that does a bit more handholding. Sorry for that.

And as stated: the upcoming 13 will have 7.2 support and we are currently evaluating on how much effort we need to spend to backport the 7.2 fixes, but we cannot promise anything.

5) Nextcloud GmbH does not take Open Source serious

Sure - that's the reason, why we make all parts of our product open source ... we just don't take it serious. /irony

Thanks, Morris (one of many Nextcloud contributors who spends a s**tload of (also spare) time to make it to what is it and is super motivated by useless rants NOT)

[eli-schwartz]

I guess it is a bit too much, to go to every single distribution out there and tell them, with what we are compatible.

I don't think that's necessary, making this more visible to users on your website should be enough. To that end, it seems like nextcloud/documentation#626 is the right direction. As you did, after all, know about it a while ago.

As we documented everywhere: please test, have backups and in the worst case roll back to the backup. Sorry to say this and this sounds maybe a bit arrogant (which it shouldn't), but if you run something in production you should maybe test it before complaining and if you run something like Arch Linux you should know what you do - otherwise use Ubuntu or another distribution that does a bit more handholding. Sorry for that.

I'd have to agree with you on this. @Natanji, Arch isn't really the best distro to use if you have high uptime requirements from your production server. We do our best, and it usually works pretty smoothly, but there will always be situations where we move faster than some downstreams. Things can break, we just try to keep that to a minimum and hopefully in ways that users always know how to cope with a minimum of fuss. At the very least, run a staging server to test updates before you roll them out to the main server...

And as stated: the upcoming 13 will have 7.2 support and we are currently evaluating on how much effort we need to spend to backport the 7.2 fixes, but we cannot promise anything.

Thank you for considering this. Ultimately, that's all we can really ask for.

[Natanji]

First off I want to apologize for my tone here, you're right that it wasn't okay and I definitely made some remarks in my frustration about this that were more heated than they should have been and stepped over a line (in particular, I edited out the part @LukasReschke mentioned). (I also never meant developers to read the rant over at Mastodon. I was venting elsewhere precisely to not burden developers with this. It was unfair. I guess Mastodon isn't as private as I perceived it to be. I already asked @saper to remove that link, maybe @MorrisJobke can consider that too.)

@MorrisJobke: I also thank you for your reply, especially stating that you will consider if making Nextcloud 12 compatible is possible. What made many users here (me included) so angry was two things: first, that you knew about this problem for months, but didn't make this info very visible, e.g. by updating the documentation. And secondly you closed this without anyone communicating that you would at least consider backporting the 7.2 support. Together, this came off as "yea we know about this problem but we don't even care that things might break". Your clarification sounds way differently.

I still believe you should evaluate better methods of informing maintainers of known incompatibilities/breakages like this, like many other FOSS projects do. Perhaps you could just create a mailing list for maintainers where you selectively push out such info (with a publicly searchable archive - like a standard mailman installation)? There is no need for you to go out there and handhold every single distribution, nobody expects that! But having one well-defined channel where interested parties such as maintainers or admins can subscribe and will be informed precisely of such problems doesn't seem like too much to ask. (I did see that you have "newsletters" but I couldn't find archives for those, and none of them seem focused on that specific topic)

I'm still frustrated because the whole situation just seems so very... unnecessary because a visible publication or advisory that Nextcloud 12.x.x would not be compatible with PHP 7.2 could've prevented a lot of the work that now has to be done. I mean, you did know about this for so long... maybe you didn't expect PHP 7.2 to hit yet or something?

I want to point out that I never claimed Nextcloud GmbH was not taking FOSS seriously; in fact I did state the opposite of that, I'm sure you folks want to do so and that is great. Which is why I would expect that you'd want to align yourself with tried concepts from the rest of the FOSS world (see above). Similarly, I never claimed that you wouldn't test against the beta 3, but quite the opposite: my expectation was precisely that you had done this, and therefore did know about this problem for a long time already, like you say you did. It's just sad when this information doesn't reach package maintainers.

I'll try to not comment here any further now, I'm certain everything has been said by now. I'll try to focus on helping downstream deal with this somehow and keep any more of my whining to different places such as Mastodon, where you don't have to see it.

[My1]

sorry in advance if I may sound rude, this is not my intention.

---

sorry if I have to ask but wasnt it possible to do the fixes in the pre-release period of PHP7.2? tests is one thing, but it not running with new PHP versions should be communicated in a better way. (for example the docs dont state that 7.2 doesnt work)

I ran iirc the last beta and most of the RCs and saw no big problems on the PHP side that would have prevented doing webdev on PHP 7.2RC.

regarding versioning. sure no problem that 12.0.x wont support newer PHP, but what about adding a 12.1 which does?

also compare with wordpress, they have been doing PHP7.2 work basically since the alpha stage and have been ready about 2 months before PHP7,2 released, even though they have a far bigger problems with relics of the past since they go back to 5.2, which has been EOL for almost 7 years and was released over 11 years ago.

also when mcrypt is the problem I honestly wonder why. mcrypt has been deprecated on 7.1, meaning that 12 should have done something to make the transition a bit smoother, because while I wont say much about 11, which already was released past PHP7.1, 12 should certainly have switched to openssl or something similar.

[Zepmann]

Here are my $ 0.02:

I do not mind that NC12 is not compatible with PHP 7.2. Sure, some effort could have been put into it to make it work, but I can understand that the changes under the hood might not fit a minor release, and that the developers rather put that work in NC 13.

However, I do agree with the opinion of some users that this is poorly communicated and that this is not made clear in the documentation. The documentation tells us:

PHP 5.6 + required

PHP 7.0 + (recommended)

The Linux specific page mentions it correctly, but this discrepancy will still confuse admins. I recommend that this is fixed and that communication about these requirements for the foundation on which NC runs should improve.

Do not worry too much about Arch Linux admins. I am one of them, and this is something an admin living on the bleeding edge must deal with. Just help us a little bit by communicating changes in requirements more clearly beforehand, so we can help others by describing possible mitigations. :) An example:

1. Uninstall the existing PHP package.
2. Download php70 from the Arch User Repository.
3. If you use the Arch Linux Nextcloud package, modify the PKGBUILD according to the instructions by aexoxea. I only needed to modify php-gd to fulfill Nextcloud's package requirements, but your results might differ.
4. Build and install.
5. Migrate the previous configuration from php to php70.
6. Carry on.

Once NC13 is released and installed PHP can be migrated back to the official Arch Linux package.

[steadybright]

@Zepmann , thank you for you helpful, constructive post. I ended up rolling back my system to 12/1/17, set pacman to ignore PHP updates for the time being, and all is well again. Like you, I found that php and php-gd were the two packages in conflict.

[tkuther]

No need to uninstall php from core or edit/rebuild the nextcloud package.

Installing php70 from AUR is enough as it has a provides for php=7.0.25 which makes the nexcloud package happy. Then update webserver config accordingly to use the right php70-fpm backend (or php module)

[SeeSpotRun]

Thanks @tkuther.

I noticed nextcloud-git (13.0.0beta1) in the AUR - I guess this is another workaround although I confess I took your option.

[jaltek]

You could also try to downgrade your PHP versions by using the old packages in your local cache (if still existent):

/var/cache/pacman/pkg

Or you can simply downgrade the packages by using the Arch Archive:

https://archive.archlinux.org/packages/p/ https://wiki.archlinux.org/index.php/downgrading_packages

As @tkuther already mentioned there is no need to uninstall the php packages if you choose the "AUR" way. But if you want to do so and want to uninstall the new 7.2 version, beware that pacman will also remove the config files like php.ini, fpm etc.

[HLFH]

The question is: using PHP 7.2, can we upgrade to NC13 from N12, with ./occ command ? It does not seem to work. Or is there a git method? I don't like downgrades.

[z3ntu]

@jaltek I wouldn't use the Arch Linux Archive for downgrading php as there could be updated dependencies that could lead to linking conflicts. The php70 package from the AUR works for me (even though I had to re-do the php.ini in /etc/php70)

[Natanji]

@HLFH Isn't the ./occ command run after you already updated the package/the Nextcloud files to NC13, which does support PHP 7.2? As in, you do run the NC13 occ update command, not the NC12 one because NC12 doesn't know anything about the changes to migrate to NC13. I'd be surprised if it does not work, if it doesn't then that seems like an unrelated NC13 bug (since NC13, and thus its update routine supports PHP 7.2).

@jaltek I can confirm what @z3ntu says. You can't downgrade just a few packages. The php70 method works okay for now, even though the PKGBUILD is a bit broken (look at the last comment in the AUR).

[jaltek]

From the Arch Wiki:

This process will remove the current package and install the older version. Dependency changes will be handled, but pacman will not handle version conflicts. If a library or other package needs to be downgraded with the packages, please be aware that you will have to downgrade this package yourself as well.

So - sure you can. But it will have for sure downsides and you have to take care of the dependencies. Depending on the modules you use the dependencies for php are manageable (IMHO).

Nevertheless - this is out of scope of the issue. Yes, it is an issue which has to be resolved but it's not the end of the world. If someone broke his NC installation because of this and really depend on a working instance, then maybe a rolling release distro is the wrong way or consider using containers.

[HLFH]

@Natanji

This version of Nextcloud is not compatible with PHP 7.2.
You are currently running 7.2.0

No, sadly, I'm stuck on NC12 that is no longer working, because of PHP 7.2. I would love to upgrade NC12 to NC13, instead of downgrading PHP to 7.0.

[Natanji]

@HLFH Have you replaced the nextcloud package with the nextcloud-git package? It doesn't seem like you did.

[HLFH]

@Natanji I rarely use awful AUR packages when the PKGBUILD are installing the softwares to dirty places like /usr/share/webapps/, /var/www... IMHO, /srv/http is the best path but AUR webapps packages rarely go to this location.

For Nextcloud, I usually install it from command line, and upgrade it via built-in updater.

I finally solved this issue by:

0. Get the .tar.gz v13.0.0beta2 releases for nextcloud/server & nextcloud/3rdparty
1. Do the manual upgrade
2. Do not forget to install 3rdparty
3. Disable crappy integrity check within config.php: 'integrity.check.disabled' => true,

[CountMurphy]

@HLFH you realize that arch officially installs nextcloud in /usr/share/webapps right? Pretty sure thats why the AUR packages install it there too. Not saying its an issue, just pointing it out.

[HLFH]

@CountMurphy I realized but thanks for the reminder. It has always been an issue on GNU/Linux not to have a 100% unique standard location for webapps & websites. But it's off-topic.

[bobpaul]

PHP7.1 is supported until 1 Dec 2019 and 7.2 is marked as a not-backwards compatible; it's not unreasonable for an app like NextCloud to delay supporting the latest. There's still apps in Arch that depend on Python 2.7... I'd rather not risk major bugs getting introduced into 12.x due to porting to PHP7.2. NextCloud 12 should really be stable at this point with new features (like language upgrades) going into the next release.

This is an Archlinux bug (both PHP and NextCloud are official packages; they shouldn't have upgraded php without testing NextCloud. Regression testing fail :-/). This is why rolling releases like Arch and Gentoo are frequently discouraged on servers. I love arch and I'm dealing with this issue via IgnorePkg for the moment, but blame where blame is due. I guess I might setup a Debian Chroot via systemd-nspawn.

[bobpaul]

@HLFH /srv/www, /var/www/ etc generally don't have files owned by packages. Certainly Gentoo, Arch, Debian all put webapps maintained by distro packages somewhere else (like /usr/share/webapps). I think one of the reasons for this is to make it easier to have multiple websites depending on the same webapp, such as running multiple NextCloud instances responding to different FQDNs. You can usually set things up so domain specific config to somewhere like /etc while the shared files maintained by the package are in /usr/share.

[bjoernv]

openSUSE Tumbleweed also updated to PHP 7.2 now and Nextcloud 12 does not work anymore. There is a downgrade repository (PHP 7.1) for openSUSE Tumbleweed users: https://download.opensuse.org/repositories/devel:/languages:/php:/php71/openSUSE_Factory/

[Tyil]

@bobpaul Gentoo's portage won't upgrade PHP to 7.2 if the OwnCloud package is indicated to require php <= 7.1. It also allows easy "masking" of PHP 7.2 in case you do not want/need it (yet). Gentoo on a server won't pose any problems with NextCloud usage.

[virtualdxs]

@HLFH I would NEVER want a package to install to /srv/http. /usr/share/webapps is where most webapps go and you can either symlink or copy or do whatever you want there.

[saper]

Thank you for the discussion, I think there is nothing more to be added here.

[arendtio]

@saper Actually, I have the feeling that the underlying problem wasn't even mentioned yet: This wasn't the first time that the current version of Owncloud/Nextcloud is incompatible with an upcoming version of PHP. Every time this happens, it causes a mess for everybody who blindly assumes that Nextcloud supports the latest PHP version (finding out about the breakage, restoring backups, downgrading the PHP version, etc.).

To solve this problem it would be great if the Nextcloud devs could implement a process to check the compatibility of Nextcloud against an upcoming PHP version before it is finally being released to the public and release a compatible version of Nextcloud before the new PHP comes out. I am aware that this will cause some extra effort for you, but as the compatibility changes have to be made anyway and it would ease the life of a lot of people on the other side of the table, it should be a fair solution.

[My1]

@arendtio This, This would be so great and really helpful.

[SeeSpotRun]

@arendtio, given that (1) php made backwards incompatible changes on a point release, (2) different distro's roll out those changes at different times, and (3) the timing overlaps with a heavy development workload getting nextcloud 13 production-ready, I think that on this occasion to "release a compatible version of Nextcloud before the new PHP comes out" was probably a bit too much to ask.

[alerque]

@SeeSpotRun ① This wasn't a point release. If you follow the PHP project you'd know that major changes are regularly included at this numbering level. Point releases that aren't supposed to break anything are the next level of numbering in PHP's scheme. ② This is why a major project like Nextcloud should stay on top of upcoming releases to the language they use, not stay behind and wait until after everything goes sideways for the earlier distros. ③ Nevermind the development cycle, just the release cycle from when alpha's were posted was over 6 months long and spanned 4+ Nextcloud point releases. Getting some new development branch production ready shouldn't have taken priority over existing production systems. At the very least the last 4 point releases should have come with packaging warnings about the new PHP so packagers would have known to hold back PHP packages in their distros. As was covered above developers know about this upcoming problem and didn't communicate it over release channels where it would have mattered.