Core packages:
scl-utils: for sc usage (sclcommand line tool)scl-utils-build: for sc building (rpm macros, ...)
Example of sc:
- collection name:
rh-ruby22 - ruby package from there:
rh-ruby22-ruby
Example: listing collections:
# scl --list rh-python35 # scl --list rh-python35 rh-python35-python-setuptools-18.0.1-2.el7.noarch rh-python35-python-virtualenv-13.1.2-1.el7.noarch rh-python35-scldevel-2.0-2.el7.x86_64 rh-python35-runtime-2.0-2.el7.x86_64 rh-python35-python-libs-3.5.1-6.el7.x86_64 rh-python35-python-pip-7.1.0-2.el7.noarch rh-python35-python-devel-3.5.1-6.el7.x86_64 rh-python35-2.0-2.el7.x86_64 rh-python35-python-tools-3.5.1-6.el7.x86_64 rh-python35-python-3.5.1-6.el7.x86_64
Running aplications directly:
# scl enable rh-python35 'python --version' Python 3.5.1 # scl enable rh-python35 -- python --version Python 3.5.1 # echo 'python --version' | scl enable rh-python35 - Python 3.5.1
Or running bash:
# python --version Python 2.7.5 # scl enable rh-python35 bash # python --version Python 3.5.1 # echo $X_SCLS rh-python35 # exit # python --version Python 2.7.5
General overview:
- create Metapackage for the new software collection, installs the core packages of the collection
- specify
%_scl_prefix- root dir of the collection, (WTF? notroot) - prefixing the name of your Software Collection packages
with vendor and software collection name (WTF? not
scl_prefix) - specify other collections as dependencies
TODO: subcollection of
rh-python35 - convert conventional spec files via
rpm2scl - rpmbuild
The Software Collection Root Directory:
%global _scl_prefix /opt/provider
Where provider (aka vendor) is LANANA registered name.
So that the structure is:
/opt/provider/software_collection_1 |- /root `- scriplets (eg. enable)
The layout:
/opt/provider/software_collection_1 /opt/provider/prefix-application-version/ (WTF? Isn't this a bug?)
The Software Collection Prefix has 2 parts:
- provider part
- name of the collection part
Eg. myorganization-ruby193
Software Collection Package Names:
- prefix part
- name of the application (conflict with prev. example)
Eg. myorganization-ruby193-foreman-1.1
TODO: review the conflicts and propose a fix here
Contains basic file system hierarchy, scriplets and requires all core packages of the collection (which needs to be installed).
Produces packages:
- The main package:
%name(eg.myorganization-ruby193) (just list of dependencies) - The runtime subpackage:
%name-runtime(filesystem structure and sniplets) - The build subpackage:
%name-build(rpm macros) - The scldevel subpackage:
%name-scldevel(for development of dependent software collections)
Creating metapackage, define macros:
scl_name_prefix(eg.rh-)scl_name_base(eg.ruby) (but other parts referst this is just name)scl_name_version(eg.193)nfsmountable(suggested, optional)%setupand%prepshould be provided
Example of metapackage spec (just a header):
%global scl_name_prefix myorganization-
%global scl_name_base ruby
%global scl_name_version 193
%global scl %{scl_name_prefix}%{scl_name_base}%{scl_name_version}
%scl_package %scl
%global _scl_prefix /opt/myorganization
Summary: Package that installs %scl
Name: %scl_name
Version: 1
Release: 1%{?dist}
License: GPLv2+
BuildRequires: scl-utils-build
Specific macros with default values one doesn't need to chage:
- %scl_name software_collection_1
- %scl_prefix software_collection_1-
upstream: https://www.softwarecollections.org/en/docs/guide/ downstream: https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/2/html-single/Packaging_Guide/index.html list: https://www.redhat.com/archives/sclorg/
https://developerblog.redhat.com/2014/12/04/add-packages-to-python-2-7-software-collection/comment-page-1/ http://developers.redhat.com/blog/2015/01/07/using-mock-to-build-python27-software-collections-packages-for-rhel6/ http://developers.redhat.com/blog/2014/09/04/how-to-create-dependent-software-collections/
rh-python34 build in copr rh-python35 build in koji (cbs, centos koji instance)