Solved Avoid upgrading to PHP 8.0

france75006

france75006

Since lang/php74 has recently been marked as "deprecated" (while it is officially supported until November 2022) my server is now proposing to upgrade it to lang/php80. The problem is that www/dokuwiki isn't ready yet fort that version and so I'm compelled at the moment to hold back that, and all the other packages updates proposed.

I'm aware that I cannot choose a different default version, as I used to do when using ports, so is there another path I could take to hold back only that upgrade for some weeks/months more? Is pkg-set(8) (which I've never used) intended for that?

Thanks in advance,
Francesco
 
Right, so if I do a

PHP: 
pkg info -r php74

I get

Code: 
php74-7.4.27:
        php74-gd-7.4.27
        php74-json-7.4.27
        php74-mbstring-7.4.27
        php74-openssl-7.4.27
        php74-session-7.4.27
        php74-xml-7.4.27
        php74-zlib-7.4.27
        dokuwiki-20200729

Shall I lock all those packages? Of course, I will not be able to update to PHP 7.4.28, after that.

Thanks again,
Francesco
 
While you've been already pointed to pkg lock:

lang/php74 is planned to be removed on 2022-11-29; The deprecated notice is: A notice for you that just says "Upstream Security Support ends on 2022-11-28", and doesn't mean that it will be removed immediately.

Also the author of DokuWiki announced PHP 8 bugfixes for the next release.

Shall you lock all your PHP packages? I would expect that just locking php74 would do the trick. How to update PHP 7.4 then? Unlock that package, and execute pkg install php74, and then lock it again; Afterwards the normal update will also update you PHP extensions.
 
I've been obliged to lock 3 packages because of the forced installation of php80 (and deletion of php7x).

I didn't expect that from FreeBSD (even if I use the latest repo).
 
Emrion, different versions of PHP packages can't coexist, so there must be a default version used for everything that depends on PHP. Moving that to PHP 8 now makes sense... (given nothing in the ports tree has problems with that version, which I assume)

Using binary packages, you're still free to explicitly install PHP 7.4 instead. Of course, if you use other packages depending on PHP, this would pull in PHP 8 as a dependency, so in that case, your only option would be to "lock" the packages.

In a nutshell, mixing PHP-dependent packages with locally installed PHP-dependent software doesn't work out well. You could of course build from ports yourself, then you can just set DEFAULT_VERSIONS+= php=7.4 in make.conf, so anything will depend on the older version.
 
blind0ne said:
I would do that, why not.
Click to expand...
It's only a short-term solution. You will also implicitly lock dependent packages. What if a security issue is fixed in one of them?

If it's forseeable that whatever needs older PHP on your system will be updated soon, fine. If you need to keep PHP 7.4 for months, building from ports might be the better idea...
 
Of course it would be an interesting feature for pkg(8) to be able to pull dependences following a default_version setting. But surely there are technical reasons beyond my understanding if that option doesn't exist!
 
Last edited:
I know this is an old thread, but I think it's worth noting here that WordPress, which could arguably be the most common use of PHP on FreeBSD, is still in "beta support" of PHP > 7.4.

make.wordpress.org

PHP Compatibility and WordPress Versions

WordPress aims to support new versions of PHP on the day they are released as much as possible. As a project, the process of supporting these new versions begins after each new PHP version has hit …
make.wordpress.org make.wordpress.org

That makes this bump seem a little hasty, even now, in 2023.
 
From that perspective, I couldn't agree more. But WordPress powers forty three percent of all sites. And sadly, EOL doesn't always mean end of use.
 
You must log in or register to reply here.
Back
Top