Hi, I am currently on PHP V7.0 as part of a llmp selection. I note the latest stable is 7.3 which it looks like DietPi would install on a fresh build.
How can I safely upgrade PHP?
Is there anyway of identifying to a user that there is a newer stable version of an installed application?
Currently we install the PHP version that is served by the Debian repo. On Stretch this is PHP7.0 and it this is not going to be updated there. Debian Buster ships PHP7.3 and is about to be released this summer.
But we are thinking about shipping a more current PHP version on Stretch from 3rd party repo, since some software titles are going to drop PHP7.0 support: https://github.com/Fourdee/DietPi/issues/2367
It will be most likely PHP7.2 since PHP7.3 is not yet supported by many other software titles.
You can try it out manually by using the following repo which is from the Debian repo PHP maintainer: https://deb.sury.org/
But in case you need to port some settings applied by DietPi software installs, at least /etc/php/7.0/mods-available/dietpi.ini. Also currently this will break any dietpi-software install/reinstall runs where PHP is included.
Ok Thanks. When I looked at the DietPi-Software script it seemed to reference 7.2. Perhaps I was mistaken.
Yes porting between versions of PHP is a pain. I’ll leave as is for now.
Would moving from 7.0 to 7.2 be user selectable?
Thinking about moving to Buster, will there be the same issues there were when the jump was made to Stretch (i.e. no upgrade path)?
Not sure what you mean?
On Stretch, PHP7.0 will be installed automatically, on Buster PHP7.3 (it was PHP7.2 before, since Buster just moved to PHP7.3 not long ago). Currently there is no way to choose the PHP version in DietPi-Software.
If you install PHP7.2/7.3 on Stretch via mentioned custom repo, then this will be installed system wide, although it is possible to keep the old version active besides. You can run several PHP versions in parallel, although this is of course not recommended in terms of resource usage and the global PHP commands (php, phpenmod/dismod and such) are attached to the last installed version/package.
Note that Buster is currently not officially supported by DietPi, although we would assist fast with found issues, as also we aim to have DietPi fully Buster compatible until official Debian Buster release this summer. There are experimental Buster images for VMware and VirtialBox and e.g. I run my private RPi on Raspbian Buster DietPi, but we did not yet test all software titles with it and some are even known to fail, e.g. when their custom APT repo simply does not yet contain a Buster branch.
Since ~1 year I test most changes and software I touch in code on the Buster virtual machine as well and fix issues I find. But as said, some are still open.
Debian Buster works very stable here. You will face maaaaany APT upgrades, compared to Stretch, several every day. Although this has become slightly less since some days ago the first feature freeze stage has been reached.
Raspbian Buster on the other has shown to be very unstable. Regularly APT package updates are available, but not all dependencies updated accordingly. A forced upgrade sometimes would remove a large part of the whole system due to missing dependencies. E.g. when PHP7.1 was shipped to Debian Buster, just “some” packages on Raspbian were updated accordingly, other not. So when upgrading one was left with a half working PHP. Exactly the same occurred when PHP7.2 and finally PHP7.3 was shipped. With some Python and MariaDB upgrades (and other I forgot) it was the same. Very annoying, and absolutely not recommended from my point of view, even for testers frustrating.
About jump to Buster:
It never was and will never be supported to upgrade from one distro version to the next. Independently from DietPi this is never recommended and always a risky step. You never know which package upgrade combination will run into issues, leaving you on a stage somewhere between Stretch and Buster, you will have old config files in place, where a fresh Buster would ship updated ones, and other perhaps obsolete or conflicting system features/services. And of course all software that was not installed from the official APT repo might depend or be configured to work on Stretch, but not on Buster.
Of course there are many cases where it went fine without much manual post maintenance, but this can be never assured, not by Debian and not by DietPi. So we can never offer/support this as official update path. Instead we will ship fresh Buster images, after Debian has moved it to stable.
You implied you might consider moving DietPi to 7.2 and I was wondering if that would be something that could be user selectable i.e a user choose whether to move to 7.2 or stay on 7.0.
On moving, fully appreciate the issues, just wanted to confirm that would be the position as and when Buster appears and you decide to make the switch. Cheers.
Ah, I think when switching on Stretch to PHP7.2, we will do that for all images and patch on existing installs. It is simply to complicated and enables too much additional testing cases, if we’d allow to run either the one or the other.
Also there is no benefit to stay with PHP7.0, if PHP7.2 is proven to work with all software titles. Of course we would migrate all DietPi related config changes automatically then and inform user on update, to migrate own manual config changes as well.
But yeah, this is still case of discussion, nothing final.