Re:Software Collections
by m_rcin on Saturday May 10, 2014 @05:50PM
(#7726958)
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.
Re:Software Collections
by webmaven on Saturday May 10, 2014 @09:56PM
(#7727409)
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.
Re:Software Collections
by SEJeff on Saturday May 10, 2014 @06:51PM
(#7727087)
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"
Re:Software Collections
by ctdavies on Saturday May 10, 2014 @04:29PM
(#7726767)
"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.
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.
Nixos approach is a lot nicer, if less practical.
* 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...