slack15 and php EOL
 

php 7.x is end of life, no updates security or otherwise at January 1 2023, 3 weeks from now :)

I see 8.1.x is in extra and should be supported for 22 months, is anyone running this version?

Any hiccups with anything you were running, blogs, forums, carts, whatever?

It's worse than that
php 7.4.x is EOL since Nov. 28, 2022 ...
https://www.php.net/eol.php

I've been using PHP 8.1.x for some time, compiled from sources (my old habit) and I have no compatibility issues with what I need (Apache, Joomla, Roundcube).

I am guessing when v7 is EOL, Pat will most likely just version bump security updates to the 8.x series, and so most likely everyone by then will have most likely installed the 8 or 8.1 from /extra ?

OR, more probably he will just stop pushing updates for v7, as nothing new will be available. Just like he did with the other/older releases.

How you people loves to compare Slackware with RHEL, I would say that RHEL itself will maintain 10 years the included in a release, BUT even Slackware maintains 10 years also a release, the Slackware depends on upstream, hence The Team cannot maintain the included software for 10 years.

So, the cake is a lie! ;)

I don't know how you jumped to that conclusion; RHEL probably has the resources to maintain an EOL package on their own - Slackware does not. Overall I do not understand your post, so what is your proposal? Just stay an an EOL package? Pat is just to write up patches himself for php7 then?

If we look on what Slackware did on the previous -stable releases, I bet that Slackware 15.0 will stay on the last PHP7 release, once it's public available. Because, this what was did in the past and just like you said, Slackware has no resources to maintain EOL packages on their own.

Maybe you have unrealistic expectations from Slackware and its release 15.0 ? :D

It's obvious that The World moves too fast for Slackware...

In my humble opinion, more realistic will be a release cycle of one year and a support period of one year or two. Anything else is exactly what you are about to learn: maintaining yourself the software. DIY.

Maybe, or if the package is EOL - and php8 and 8.1 is already in /extra I do not see why Pat won't just start on that and include security updates from there.

Not really I just tend to go with the flow.

Sure this last release was a long wait; I however do not have the expertise or the time to assist in the endeavor , perhaps you do - if so why not contribute?

Ok, join the team and develop - I myself do not really care - if I were so concerned about a faster release cycle; I would have used a different distro as my main distro. I also again do not have the time or the knowledge to offer assistance to Slackware. I just use it , just because it happens to be the first distro I was introduced to, and always end up coming back.

As LuckyCyborg writes, mostly when a package becomes EOL or when a package stops compiling on a "maintained" version of Slackware that package will no longer get any updates. This applies not only to php, but also other packages like firefox and thunderbird.

On the other hand, during the times, it has happened that packages in the extra directory gets security updates. At least this has happened for wicd which then was in the extra directory. Usually you do not want to install a patch like that unless you already have the package (in this example wicd) installed, but when it comes to php8 it might be a good idea to install security updates when php7 is EOL.

regards Henrik

Guess what? The Slackware 15.0 have in /extra both PHP80 and PHP81 which packages are maintained with security fixes, in parallel with the ones for PHP7 . And this way I believe that will continue until all 2 of them goes EOL.

So, in a sense the concerns of this thread are a no issue. Because there will be a maintained PHP on Slackware 15.0 until ALL of those 3 versions will go EOL.

However, seems like some people does not understand really the Slackware (or any other Linux distribution with point releases) Architecture and that a -stable release is not a rolling release. I for one, I have heard long time ago that -stable release means a stable API and ABI. You want more? DIY or jump in a superior release.

So, in fact the solution for having ALWAYS a maintained PHP in a -stable release is you guys to "persuade" Slackware to seriously shorten its release cycle. One release per year will give you really what you want. Go wild and seriously ask for this.

I just upgraded my workstation to Php8.0.
The php.ini which comes with php 8 tries to load extension xmlrpc.so which doesn't exist any more. This generates all kinds of warnings.

I use weberp for accounting, this relies on xmlrpc.so to print pdf files. This is not a Slackware problem.

Just my thoughts.

Don

Never gonna ask for that... 5 years is fine, though close to be over the top! :D

Of course requests can be made, but definitely really want to stick with the Slackware Philosophy.


Are you sure you won't prefer Fedora a.o. fast-pace distros?

Thanks, I do build 7.4 from source because of gd issues requiring X libs, I was going to try 8.1 in extra to see if the issue remains before I build source.
cheers


(sorry for delay reply, I am not once again getting notifications from LQ, not blacklisted, just not sending)

I found the same issue after upgrading to 8.1.12 ponce informed me that the solution to this was to comment
from my php.ini

For me this was acceptable as I don't use it, though I did get some other errors when testing some code for issues.
NOTE: If you're upgrading from php 7 to php 8+ I recommend you update your pear modules if any are installed especially pear::mail

Regarding xmlrpc, from what I can tell this appears to have been abandoned for some time and unlinked from PHP.

xmlprc can be installed through pecl (https://pecl.php.net/package/xmlrpc) however by running

pear should likely be checked for upgrades first though.

I did come across this site which does list alternatives which are likely maintained

https://php.watch/versions/8.0/xmlrpc#alternatives