Familiar with Software Collections concept?Shortly, the Software Collections (SCL) concept is a really cool technology, that is especially usable on RPM-based Linux distributions that deliver one version of a component and support it for long time, like Red Hat Enterprise Linux or CentOS. SCL allow you to install a newer (or just different) version of any component without affecting the rest of the system (which is crucial).
That all is done by installing files into separate directories that don't collide with the base system. For Software Collection called rh-mariadb101 (that delivers MariaDB 10.1 Server), the files are located at:
- /opt/rh/rh-mariadb101/root/usr/bin (binaries)
- /etc/opt/rh/rh-mariadb101/my.cnf.d (config files)
- /var/opt/rh/rh-mariadb101/lib/mysql (data)
- /var/opt/rh/rh-mariadb101/log/mariadb (error log file)
Why this is not enough?This all has worked very well for several years and people love SCL. 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
What to do with that?The approach I prefer is based on two changes:
- have a symlink on usual places in /etc/ and /var to make it easier for users to find the stuff they're looking for
- have a wrapper for every binary, the wrapper is located in /usr/bin, so no scl enable is needed; the wrapper runs scl enable internally and then executes the binary located under /opt/rh/rh-mariadb101/root/usr/bin
The wrapper is quite easy and can be shared (symlinks then head to the wrapper); the wrapper can be then located in /opt/rh/rh-mariadb101/root/usr/libexec/scl_wrapper:
#!/usr/bin/bashFor example mysql tool is then available by having such a link:
source scl_source enable @SCL@
exec `basename "$0"` "$@"
/usr/bin/mysql -> /opt/rh/rh-mariadb101/root/usr/libexec/scl_wrapper
Both, the wrappers and the symlinks, are available in a separate sub-package, so just having them available does not change anything for currently working solutions, which I really like about this approach honestly.
It means only users who would like to use the Software Collection packages as normal components will be allowed to install a rh-mariadb101-mariadb-system-widesub-packge (cool name, huh?). Those users will need to accept the fact that they cannot install mariadb and mariadb-server packages from the base system any more, because those will obviously conflict with the rh-mariadb101-mariadb-system-wide package.
Does it really work?A working solution is also available in my testing Copr repository:
For dependencies, you need either Red Hat Software Collection channel enabled on RHEL-7, or use the packages from the SCLo SIG group on CentOS 7. See more info at:
That Copr will show you, that after installing the package rh-mariadb101-mariadb-system-wide, you can start doing things like the MariaDB 10.1 Software Collection would be normal package:
#> service mariadb start
#> service mariadb status
#> echo "select @@version;" | mysql
#> mysql_upgrade --force
#> less /etc/rh-mariadb101-my.cnf
#> less /etc/rh-mariadb101-my.cnf.d/mariadb-server.cnf
#> ls /var/lib/rh-mariadb101/
Feedback required!Now, the most important thing -- the reason I shared this post here.. I want to hear feedback from current Software Collections users, whether this idea helps to overcome the Software Collection design issues and whether there are some more ideas.
For feedback, use ideally our mailing list firstname.lastname@example.org.