On 03/21/2017 06:04 PM, Vacelet, Manuel wrote:
On Tue, Mar 21, 2017 at 4:05 PM, Honza Horak <hho...@redhat.com
<mailto:hho...@redhat.com>> wrote:
This is basically a kick-off for getting more feedback for an idea
shared at
http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html
<http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html>.
Shortly, SCL has worked nicely for several years and people love
them. But even the beloved ones have some issues. And what we hear
from users, the issues with Software Collections concept currently
are basically those:
* we need to use scl enable, which changes $PATH and other
environment variables, so the binaries placed in different location
are visible by the system
* scripts originally written for "normal" MySQL use full paths (like
/usr/bin/mysql) which does not work when we only have the Software
Collection installed
* Data directory, config files and log files are on different
location than it is common
The blog post tries to summarize possible solution, which I'm
looking for feedback now, ideally by replying to this mail..
Hi Honza,
I do love SCLs and I share most of the pitfalls you raised about using
them (I would have loved not to write tons of custom scripts to manage
my various parallel PHP / Nginx versions on my systems).
Do you foresee a way to deal with package dependencies ?
I might be wrong but when I'm installing packages that requires
php(language>=5.3) it doesn't see rh-php56 or rh-php70 scls
It's a bit cumbersome because I end-up having the default package
installed whereas I'm only using the ones that come from SCLs
Interesting point. In case php(language) is common in php world, then
someone might expect php from base is installed when asking for such
requirement and thus adding the same virtual name into rh-php56 or
rh-php70 scls might make troubles. Or maybe more important issue -- if
modules are meant to work with php 5.5, then they might break with 5.6,
especially in case of binary extensions. That's why the original idea
was concerning the daemon SCLs like databases only.
Last, as an alternative to wrapper package, I find useful the
"update-alternative" from debian.
It's pretty much the same thing (links AFAIK) but switch is done with a
command rather than a package install.
Yeah, it would be nice, although I'm not sure entirely how this concept
works with tens of binaries (requiring to run alternative command for
every binary would not be very nice). Also, alternatives require all of
the alternatives to support this method, which we are not able to do in
RHEL-7/CentOS-7, because it would mean to change packages from the base
system.
Honza
_______________________________________________
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg