SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I assume current will bump to 7.x because it make s little sense to ship EOL'd software in the distro. I am not sure what to expect for 14.x because 5.6 - > 7.x has all kinds of breaking changes for apps; that you would not expect in a stable platform update.
I assume current will bump to 7.x because it make s little sense to ship EOL'd software in the distro.
Agreed, that would (should) be a safe assumption
Quote:
I am not sure what to expect for 14.x because 5.6 - > 7.x has all kinds of breaking changes for apps; that you would not expect in a stable platform update.
Agreed, but making it available as an optional patch at least for a (controlled migration) would IMO be much better than the alternative.
I'm sitting on three 14.1 production servers running 5.6 and it would be nice to have 3 - 4 weeks making necessary code changes in a virtual copy of one of the servers before updating. Than having to sit and pray I'm not exploited and then be faced with forced server upgrades when current is moved to stable (14.3/15.0 whatever) which will create larger problems
Upgrading from 5.6 to 7.2 in Current broke almost everything for me.
Just saying... and I'm still working on it.
Yea I'm expecting that which is why I'm trying find out what the plan is.
It would be nice to make sure code works and make necessary changes before 5.6 EOL
I'm sitting on three 14.1 production servers running 5.6 and it would be nice to have 3 - 4 weeks making necessary code changes in a virtual copy of one of the servers before updating. Than having to sit and pray I'm not exploited and then be faced with forced server upgrades when current is moved to stable (14.3/15.0 whatever) which will create larger problems
Hopefully you can get an official package for php7 on 14.1, but there is no guarantee that will happen. But since Slackware is Slackware, you can always build your own package and start making the necessary changes for your sites to move to the new version.
You can grab the source from -current and see if it will build on 14.1 unmodified.
Hopefully you can get an official package for php7 on 14.1, but there is no guarantee that will happen. But since Slackware is Slackware, you can always build your own package and start making the necessary changes for your sites to move to the new version.
You can grab the source from -current and see if it will build on 14.1 unmodified.
And that likely may be the direction I'll have to go.
Perhaps someone from the dev team will chime in and provide some insight on what's planned (if anything)
I do not use PHP on my home Slackware systems, but at work I had some PHP 7.x issues on CentOS 7. The friendly point is that bumping Slackware 14.x to 7.x might cause issues. Perhaps Pat can throw PHP 7.x into /testing. After the dust settles move from /testing to /patches.
I do not use PHP on my home Slackware systems, but at work I had some PHP 7.x issues on CentOS 7. The friendly point is that bumping Slackware 14.x to 7.x might cause issues. Perhaps Pat can throw PHP 7.x into /testing. After the dust settles move from /testing to /patches.
I've thought about Apache and compared the httpd.slackbuild "configure" statements between 14.1 and current, and with the exception of two http2 lines in the current version, they're identical.
I wouldn't expect apache to have a problem but to be honest I will likely be holding my breath
Well, here's an update for anybody who might be interested.
I hope it'll save someone time chasing down requirements to get this working.
The PHP 7.2.13 slackbuild I created for Slackware 14.1 was installed and httpd (so far) appears to be running fine.
To build this I used the following:
-- From 14.1 patch/source --
php.slackbuild
-- From current /source --
php.slackbuild -- RENAMED - USED FOR REFERENCE ONLY
doinst.sh.gz -
php-7.2.13.txz.gz
php-fpm.conf.diff.gz
php.ini-development.diff.gz
slack-desc
-- From 14.1 source --
/alpine - (all files)
-- From slackbuilds.org/14.1 --
libsodium - obtain current tar.gz (I used stable)
-- TO DO --
Create a build directory (eg - php-build) and change into the directory
1) Inside (php-build) create folder - alpine > save alpine source files in this folder (nothing else needs to be done)
2) Inside (php-build) download slackbuild libsodium.tgz and libsodium-stable.tar.gz.
Unpack libsodium.tgz and move to libsodium directory. Edit libsodium.Slackbuild and change VERSION: to VERSION:-stable
Build and install libsodium package
3) Inside (php-build) create folder php and change into folder
Download all files from - current/source/php, rename php.SlackBuild to php.SlackBuild.current
Download php.SlackBuild from - 14.1/patches/source/php - No other files required
Open php.SlackBuild in a text editor and replace the configure arguments with the arguments from php.SlackBuild.current
create folder pear
You should now have the following directories
php-build/alpine
php-build/libsodium
php-build/php
php-build/php/pear
You should now be ready to build
Before installing, shutdown httpd. After installation /etc/httpd/mod_php and php.ini will need to be replaced with their respective .new files located in the directory
Once replaced, you should be able to start httpd services
-- TIP --
Before installing backup your /etc/httpd/mod_php.conf* and php.ini* files as well as php-fpm files in /etc and /etc/php-fpm/ . This will make restoring files easier if you need to revert back to 5.6
I hope this helps somebody, but I make no guarantees that something won't get messed up.
Don't forget as well - not to dissuade your upgrade efforts - that php5.6 was shipped in Debian Jessie and is in LTS mode until June 30, 2020. Debian have stated they will continue to support PHP 5.6 until that time even after the PHP team stops shipping important security patches. So importing any future security patches from Debian may be an option for people wishing to extend the life of PHP 5.6 for a longer period of time.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.