CentOS - May 2016 - Fwd: EPEL-ANNOUNCE Re: Upcoming OwnCloud changes in EPEL

On 5/21/2016 6:03 PM, John R Pierce wrote:
> i started to look at SCL and got lost pretty quickly.   I'm not 
> running OwnCloud but I've got some other php stuff thats getting 
> increasingly unhappy about the stock c6 php...
ok, I've installed php54-1.1-5.el6.centos.alt.x86_64 ...    if I run  
`scl enable php54`, will that connect it up to my existing apache, so it 
just works, or will that blow the heck out of everything on my host, or 
something else?  I'm currently using php-5.3.3-46.el6_7.1.x86_64





-- 
john r pierce, recycling bits in santa cruz

On 22 May 2016 07:01, "John R Pierce" <pierce at hogranch.com>
wrote:
>
> On 5/21/2016 6:03 PM, John R Pierce wrote:
>>
>> i started to look at SCL and got lost pretty quickly.   I'm not
running
OwnCloud but I've got some other php stuff thats getting increasingly
unhappy about the stock c6 php...
>
>
> ok, I've installed php54-1.1-5.el6.centos.alt.x86_64 ...    if I run
`scl enable php54`, will that connect it up to my existing apache, so it
just works, or will that blow the heck out of everything on my host, or
something else?  I'm currently using
php-5.3.3-46.el6_7.1.x86_64
>
The scl enable stuff just affects the command passed. It has no system wide
level effect. This is why to get a terminal session with it in affect you
use scl enable php54 bash ... then that session will show php 5.4 when
running the php binary.

The documentation on how to actually use it for something like php in
Apache is terrible, and the general blogs on it are awful overall. Things
like doing source /opt/rh/foo/enable seem to be frequently mentioned
despite not being what the RH docs say.

There's also a lot of confusion between the CentOS SIG SCL stuff, the
official RHEL SCL stuff and the generic softwarecollections.org stuff.

As for mod_php from an SCL from my discussions with Remi on the topic he
prefers to use php-fpm in that situation rather than mod_php since that
then allows use of different php versions via passing that particular
application to a different pool and also allows you to move away from the
worker mpm and on top a more performant one since the thread safety issues
are then bypassed.

Do keep in mind that the repos only have the base php packages IIRC and
that still leaves the question of packages for all the other php libraries.
For something like upstream php that bundles everything is not a big deal,
but for other things it can be.

Personally I still prefer to use IUS in this use case due to the simpler
set up and larger repository of php libraries built against it.

Perhaps I'll dive into a blog post soon? negotiating through this stuff
with decent examples of how to make use of the various methods, along with
their pros and cons. The question comes up frequently enough on #centos
that it'd be good to have a decent write up to refer to... and with a long
time till C6 EOL and RH relying heavily on SCL for PHP5.4+ (rather than
rebasing the php in the base distro) on it I'm sure it'll become an even
more common question than it already is.

Still none of the options (RH SCL, SIG SCL, SCL.org, IUS, RemiRepo) help us
EPEL since we can only depend on what's in base or EPEL for package
dependencies, and all efforts to get SCL approved in the Fedora Packaging
Guidelines have been rejected over the past few years.

Am 22.05.2016 um 08:00 schrieb John R Pierce <pierce at
hogranch.com>:
> On 5/21/2016 6:03 PM, John R Pierce wrote:
>> i started to look at SCL and got lost pretty quickly.   I'm not
running OwnCloud but I've got some other php stuff thats getting
increasingly unhappy about the stock c6 php...
> 
> ok, I've installed php54-1.1-5.el6.centos.alt.x86_64 ...    if I run 
`scl enable php54`, will that connect it up to my existing apache, so it just
works, or will that blow the heck out of everything on my host, or something
else?  I'm currently using php-5.3.3-46.el6_7.1.x86_64


just take a look under /etc/httpd/conf.d/ and move the php.conf away to allow
the php-54.conf file to get the precedency ...

--
LF

Am 22.05.2016 um 09:00 schrieb James Hogarth <james.hogarth at
gmail.com>:
> On 22 May 2016 07:01, "John R Pierce" <pierce at
hogranch.com> wrote:
>> 
>> On 5/21/2016 6:03 PM, John R Pierce wrote:
>>> 
>>> i started to look at SCL and got lost pretty quickly.   I'm not
running
> OwnCloud but I've got some other php stuff thats getting increasingly
> unhappy about the stock c6 php...
>> 
>> 
>> ok, I've installed php54-1.1-5.el6.centos.alt.x86_64 ...    if I
run
> `scl enable php54`, will that connect it up to my existing apache, so it
> just works, or will that blow the heck out of everything on my host, or
> something else?  I'm currently using php-5.3.3-46.el6_7.1.x86_64
>> 
> 
> The scl enable stuff just affects the command passed. It has no system wide
> level effect. This is why to get a terminal session with it in affect you
> use scl enable php54 bash ... then that session will show php 5.4 when
> running the php binary.
> 
> The documentation on how to actually use it for something like php in
> Apache is terrible, and the general blogs on it are awful overall. Things
> like doing source /opt/rh/foo/enable seem to be frequently mentioned
> despite not being what the RH docs say.
> 
> There's also a lot of confusion between the CentOS SIG SCL stuff, the
> official RHEL SCL stuff and the generic softwarecollections.org stuff.
> 
> As for mod_php from an SCL from my discussions with Remi on the topic he
> prefers to use php-fpm in that situation rather than mod_php since that
> then allows use of different php versions via passing that particular
> application to a different pool and also allows you to move away from the
> worker mpm and on top a more performant one since the thread safety issues
> are then bypassed.
> 
> Do keep in mind that the repos only have the base php packages IIRC and
> that still leaves the question of packages for all the other php libraries.
> For something like upstream php that bundles everything is not a big deal,
> but for other things it can be.
> 
> Personally I still prefer to use IUS in this use case due to the simpler
> set up and larger repository of php libraries built against it.
> 
> Perhaps I'll dive into a blog post soon? negotiating through this stuff
> with decent examples of how to make use of the various methods, along with
> their pros and cons. The question comes up frequently enough on #centos
> that it'd be good to have a decent write up to refer to... and with a
long
> time till C6 EOL and RH relying heavily on SCL for PHP5.4+ (rather than
> rebasing the php in the base distro) on it I'm sure it'll become an
even
> more common question than it already is.


The retirement date for PHP54 (RH SCL) will be 
Oct 2016. Will the SCL SIG provide longer "support"?? 




> 
> Still none of the options (RH SCL, SIG SCL, SCL.org, IUS, RemiRepo) help us
> EPEL since we can only depend on what's in base or EPEL for package
> dependencies, and all efforts to get SCL approved in the Fedora Packaging
> Guidelines have been rejected over the past few years.

--
LF

On 22 May 2016 07:01, "John R Pierce" <pierce at hogranch.com>
wrote:
>
> On 5/21/2016 6:03 PM, John R Pierce wrote:
>>
>> i started to look at SCL and got lost pretty quickly.   I'm not
running
OwnCloud but I've got some other php stuff thats getting increasingly
unhappy about the stock c6 php...
>
>
> ok, I've installed php54-1.1-5.el6.centos.alt.x86_64 ...    if I run
`scl enable php54`, will that connect it up to my existing apache, so it
just works, or will that blow the heck out of everything on my host, or
something else?  I'm currently using
php-5.3.3-46.el6_7.1.x86_64
>
>
>
Since this is becoming a recurring topic as EL6, and now EL7, begin to show
their age I did a write up on the options and how to use them today:

https://www.hogarthuk.com/?q=node/15

Am 04.06.2016 um 00:47 schrieb James Hogarth:
> Since this is becoming a recurring topic as EL6, and now EL7, begin to show
> their age I did a write up on the options and how to use them today:
>
> https://www.hogarthuk.com/?q=node/15
Thank you very much for this.
Very useful.