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. _______________________________________________ SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg