"Software Collections give you power to build, install, and use multiple versions of software on the same system, without affecting system-wide installed packages." I already have that power, it's called my skillz.
Have you ever seriously used either Nix or guix? (The gnu guile port of nix). Having tried to use both, they are kind of terrible. The idea is great, but the implementation leaves a lot to be desired. The spec2scl command, while clever, is a glorified list of regex for special cased spec files, so not that great. In the end, modules are much simpler and easier to deal with, but SCL is a pretty nice implementation that still gives you the benefits of the "competition"
I've been using devtoolset (one of RedHat's SCLs, I think the first one) for almost two years. It provides the latest GCC and other tools for developers. Using it on RHEL 5 gives well optimized and portable binaries (glibc is backward compatible).
It's fantastic that RedHat provides RPMs with the latest tools for older systems.
Regarding the scl tool itself from user's perspective, it's a step back from Environment Modules that has been around for 20+ years. Some admins even replace the scl command (which just sets a couple of env. variables) with modules.
Interesting. Basically, this seems like a way to set up a dev environment with a set of packages that aren't installed globally on the system. Sort of like Python virtualenvs, but for any software package.
Could be very useful, but if it is actually aimed at developers (as opposed to sysadmins) and their workflows, it needs mechanisms to get and install software that doesn't necesarily go through the usual packaging workflow with all of its checks. If the scl equivalent of 'pip install Pillow' only gets the latest available official RPM, the utility to developers will be very limited.
8 comments
[ 5.0 ms ] story [ 28.7 ms ] thread* A build system for creating SCLs.
* A centralized hosting location for community developed SCLs.
* Developer documentation and templates for developing SCLs.
* A developer mailing list for packagers and developers depending on or creating SCLs.
http://developerblog.redhat.com/2014/04/08/announcing-softwa...
Nixos approach is a lot nicer, if less practical.
Could be very useful, but if it is actually aimed at developers (as opposed to sysadmins) and their workflows, it needs mechanisms to get and install software that doesn't necesarily go through the usual packaging workflow with all of its checks. If the scl equivalent of 'pip install Pillow' only gets the latest available official RPM, the utility to developers will be very limited.