[scl.org] Idea: Software Collections Daemons Made System-wide

[Remi Collet]

Le 21/03/2017 à 16:05, Honza Horak a écrit :
> 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.


Having an <scl_name>-system-wide package, providing a set of symlinks
looks like a nice idea

This can become hard to create, when there is multiple packages
providing commands / service: e.g

php-cli   => /usr/bin/php
php-devel => /usr/bin/phpize (and some others)
php-pear  => /usr/bin/pear   (and some others)
php-fpm   => /usr/bin/php-fpm and php-fpm.service
php-pecl-xdebug => /usr/bin/debugclient

Another possible tricky bit is the socket used

For now php-fpm listen on a network socket (localhost:9000) in base
system and SCL, so the SCL provided service can really simply replace
the system default one (like for databases).

But, if we switch to UDS in the future this will become a bit more
tricky (each SCL listen on a different UDS), symlink "could" work (this
need to be checked).


BTW a bit more simple for PHP which doesn't need any wrapper ;)
(a simple symlink to the SCL binary is enough)



Just few other comments which may help
(a bit out-of-topic with your proposal, but related to SCL usability)


- have you tried the service alias ? (exists in both SysV and systemd)


- moving <scl_name> man page to base system

As it could be consider a bit strange to have to enable the collection
to read the documentation explaining how to enable it...


- providing the module configuration file

Because "scl enable" is not the best user friendly command, and may
raise PATH overflow when used a lot, "module load" seems better (at
least to me)

This is default with scl-utils v2, but works perfectly with scl-utils
v1, just dropping the file in the right place
(/usr/share/Modules/modulefiles/)





Remi.