From 9d170c3b195f4c876857b57041cdab69f294f405 Mon Sep 17 00:00:00 2001 From: Petr Kovar Date: Jul 11 2014 15:33:22 +0000 Subject: Merge branch 'master' into comm Conflicts: en-US/Getting_More_Information.xml en-US/Packaging_Software_Collections.xml en-US/Revision_History.xml en-US/Software_Collections_Guide.xml --- diff --git a/en-US/Advanced_Topics.xml b/en-US/Advanced_Topics.xml index c7df88a..a340a47 100644 --- a/en-US/Advanced_Topics.xml +++ b/en-US/Advanced_Topics.xml @@ -41,7 +41,7 @@ If there are Provides or Requires that you need to adjust, for example, a pkg_config Provides, there are two ways to do it: - + Add the following lines in the macros.%{scl}-config macro file so that it applies to all packages in the &DSCL;: @@ -63,7 +63,7 @@ %{?scl:%filter_from_requires s|pkgconfig|%{?scl_prefix}pkgconfig|g} %{?scl:%filter_setup} - + When using filters, you need to pay attention to the automatic dependencies you change. For example, if the conventional package contains Requires: pkgconfig(package_1) and Requires: pkgconfig(package_2), and only package_2 is included in the &DSCL;, ensure that you do not filter the Requires tag for package_1. @@ -118,12 +118,12 @@ Packaging Wrappers for &DSCL;s Using wrappers is an easy way to shorten commands that the user runs in the &DSCL; environment. - The following is an example of a wrapper from the ruby193 &DSCL; that is installed as /usr/bin/ruby193-ruby and allows the user to run ruby193-ruby command instead of scl enable ruby193 'ruby command': + The following is an example of a wrapper from a Ruby-based &DSCL; named rubyscl that is installed as /usr/bin/rubyscl-ruby and allows the user to run rubyscl-ruby command instead of scl enable rubyscl 'ruby command': #!/bin/bash COMMAND="ruby $@" -scl enable ruby193 "$COMMAND" +scl enable rubyscl "$COMMAND" It is important to package these wrappers as subpackages of the &DSCL; package that will use them. That way, you can make installation of these wrappers optional, allowing the user not to install them, for example, on systems with read-only access to the /usr/bin/ directory where the wrappers would otherwise be installed. diff --git a/en-US/Extending_Red_Hat_Software_Collections.xml b/en-US/Extending_Red_Hat_Software_Collections.xml index c02ba0e..932b74e 100644 --- a/en-US/Extending_Red_Hat_Software_Collections.xml +++ b/en-US/Extending_Red_Hat_Software_Collections.xml @@ -1,15 +1,77 @@ - Extending Red Hat Software Collections 1.1 Beta + Extending Red Hat Software Collections 1.1 + This chapter describes extending &DSCL;s that are part of the Red Hat Software Collections 1.1 offering. +
+ Providing an scldevel Subpackage + Providing an scldevel subpackage in your &DSCL;'s metapackage can make it easier for users to create a dependent &DSCL;. This section describes creating an scldevel subpackage for Ruby-based &DSCL;s, ruby193 and ruby200. + + Providing your own scldevel subpackage + + In your &DSCL;'s metapackage, add the scldevel subpackage by defining its name, summary, and description: + %package scldevel +Summary: Package shipping development files for %scl +Provides: scldevel(%{scl_name_base}) + +%description scldevel +Package shipping development files, especially useful for development of +packages depending on %scl Software Collection. + You are advised to use the virtual Provides: scldevel(%{scl_name_base}) during the build of packages of dependent &DSCL;s. This will ensure availability of a version of the %{scl_name_base} &DSCL; and its macros, as specified in the following step. + + + In the %install section of your &DSCL;'s metapackage, create the macros.%{scl_name_base}-scldevel file that is part of the scldevel subpackage and contains: + > %{buildroot}%{_root_sysconfdir}/rpm/macros.%{scl_name_base}-scldevel << EOF +%%scl_%{scl_name_base} %{scl} +%%scl_prefix_%{scl_name_base} %{scl_prefix} +EOF]]> + Note that between all &DSCL;s that share the same %{scl_name_base} name, the provided macros.%{scl_name_base}-scldevel files must conflict. This is to disallow installing multiple versions of the %{scl_name_base} &DSCL;s. For example, in Red Hat Software Collections, the ruby193-scldevel subpackage cannot be installed when there is the ruby200-scldevel subpackage installed. + + +
+ Using an scldevel Subpackage in a Dependent &DSCL; + To use your scldevel subpackage in a &DSCL; that depends on a &DSCL; ruby200, update the metapackage of the dependent &DSCL; as described below. + + Using your own scldevel subpackage in a dependent &DSCL; + + Consider adding the following at the beginning of the metapackage's spec file: + %{!?scl_ruby:%global scl_ruby ruby200} +%{!?scl_prefix_ruby:%global scl_prefix_ruby %{scl_ruby}-} + These two lines are optional. They are only meant as a visual hint that the dependent &DSCL; has been designed to depend on the ruby200 &DSCL;. If there is no other scldevel subpackage available in the build root, then the ruby200-scldevel subpackage is used as a build requirement. + You can substitute these lines with the following line: + %{?scl_prefix_ruby} + + + Add the following build requirement to the metapackage: + BuildRequires: %{scl_prefix_ruby}scldevel + By specifying this build requirement, you ensure that the scldevel subpackage is in the build root and that the default values are not in use. Omitting this package could result in broken requires at the subsequent packages' build time. + + + Ensure that the %package runtime part of the metapackage's spec file includes the following lines: + %package runtime +Summary: Package that handles %scl Software Collection. +Requires: scl-utils +Requires: %{scl_prefix_ruby}runtime + + + Ensure that the %package build part of the metapackage's spec file includes the following lines: + %package build +Summary: Package shipping basic build configuration +Requires: %{scl_prefix_ruby}scldevel + Specifying Requires: %{scl_prefix_ruby}scldevel ensures that macros are available in all packages of the &DSCL;. + + +
+
Extending the python27 and python33 &DSCL;s + This section describes extending the python27 and python33 &DSCL;s by creating a dependent &DSCL;. - In Red Hat Software Collections 1.1 Beta, the scl tool has been extended to support a macro %scl_package_override(), which allows for easier packaging of your own dependent &DSCL;. - - - Note that even though the approach described below generally applies to every &DSCL; shipped with Red Hat Software Collections 1.1 Beta, there are specifics that depend on the &DSCL; you are extending. + In Red Hat Software Collections 1.1, the scl tool has been extended to support a macro %scl_package_override(), which allows for easier packaging of your own dependent &DSCL;. +
The vt191 &DSCL; @@ -28,7 +90,7 @@ This expands to, for example, python27-scldevel. - The python27-scldevel package ships two important macros, %scl_python and %scl_prefix_python. Note that these macros are defined at the top of the spec file. The definitions are not required, they only provide a hint that the vt191 &DSCL; has been designed to be built on top of the python27 &DSCL;. They also serve as a fallback value. + The python27-scldevel subpackage ships two important macros, %scl_python and %scl_prefix_python. Note that these macros are defined at the top of the spec file. Although the definitions are not required, they provide a visual hint that the vt191 &DSCL; has been designed to be built on top of the python27 &DSCL;. They also serve as a fallback value. @@ -57,7 +119,7 @@ . scl_source enable %{scl_python} - This makes the Python &DSCL; start implicitly when the vt191 &DSCL; is started so that the user can only type scl enable vt191 command instead of scl enable python27 vt191 command to run command in the &DSCL; environment. + Note the dot at the beginning of the line. This line makes the Python &DSCL; start implicitly when the vt191 &DSCL; is started so that the user can only type scl enable vt191 command instead of scl enable python27 vt191 command to run command in the &DSCL; environment. @@ -72,7 +134,7 @@ # Defaults for the values for the python27/python33 Software Collection. These # will be used when python27-scldevel (or python33-scldevel) is not in the -# buildroot +# build root %{!?scl_python:%global scl_python python27} %{!?scl_prefix_python:%global scl_prefix_python %{scl_python}-} @@ -93,7 +155,7 @@ Release: 1%{?dist} License: GPLv2+ BuildRequires: scl-utils-build # Always make sure that there is the python27-sclbuild (or python33-sclbuild) -# package in the buildroot +# package in the build root BuildRequires: %{scl_prefix_python}scldevel # Require python27-python-devel, you will need macros from that package BuildRequires: %{scl_prefix_python}python-devel @@ -239,7 +301,7 @@ Smart replacement for plain tuple used in __version__ - Install the python27-scldevel and python27-python-devel packages that are part of Red Hat Software Collections. + Install the python27-scldevel and python27-python-devel subpackages that are part of Red Hat Software Collections. @@ -275,7 +337,9 @@ Smart replacement for plain tuple used in __version__ Run the following command: $ scl enable vt191 "python -c 'import versiontools; print(versiontools.__file__)'" - The output should contain the following line: + + + Verify that the output contains the following line: /opt/rh/vt191/root/usr/lib/python2.7/site-packages/versiontools/__init__.pyc Note that the provider rh in the path may vary depending on your redefinition of the %_scl_prefix macro. See for more information. @@ -284,4 +348,535 @@ Smart replacement for plain tuple used in __version__
+
+ Extending the ruby193 and ruby200 &DSCL;s + In Red Hat Software Collections 1.1, it is possible to extend the ruby193 and ruby200 &DSCL;s by adding dependent packages. The Ruby on Rails 4.0 (ror40) &DSCL;, which is built on top of Ruby 2.0.0 provided by the ruby200 &DSCL;, is one example of such an extension. + This section provides detailed information about the ror40 metapackage and the ror40-rubygem-bcrypt-ruby package, which are both part of the ror40 &DSCL;. +
+ The ror40 Software Collection + This section contains a commented example of the Ruby on Rails 4.0 metapackage for the ror40 &DSCL;. The ror40 &DSCL; depends on the ror200 &DSCL;. + Note the following in the ror40 &DSCL; spec file example: + + + The ror40 &DSCL; spec file has the following build dependencies set: + BuildRequires: %{scl_prefix_ruby}scldevel +BuildRequires: %{scl_prefix_ruby}rubygems-devel + This expands to, for example, ruby200-scldevel and ruby200-rubygems-devel. + The ruby200-scldevel subpackage contains two important macros, %scl_ruby and %scl_prefix_ruby. The ruby200-scldevel subpackage should be available in the build root. It specifies which of the available Ruby &DSCL;s you want to use. You can also replace it with the ruby193-scldevel subpackage. + Note that the %scl_ruby and %scl_prefix_ruby macros are also defined at the top of the spec file. Although the definitions are not required, they provide a visual hint that the ror40 &DSCL; has been designed to be built on top of the ruby200 &DSCL;. They also serve as a fallback value. + + + The ror40-runtime subpackage must depend on the runtime subpackage of the &DSCL; it depends on. This dependency is specified as follows: + %package runtime +Requires: %{scl_prefix_ruby}runtime + This expands to ruby200-runtime in the case of the ruby200 &DSCL;, and to ruby193-runtime in the case when the package is built against the ruby193 &DSCL;. + + + The ror40-build subpackage must depend on the scldevel subpackage of the &DSCL; it depends on. This is to ensure that all other packages of this &DSCL; will have the same macros defined, thus it is built against the same Ruby version. + %package build +Requires: %{scl_prefix_ruby}scldevel + In the case of the ruby200 &DSCL;, this expands to ruby200-scldevel. + + + The enable scriptlet for the ror40 &DSCL; contains the following line: + . scl_source enable %{scl_ruby} + Note the dot at the beginning of the line. This line makes the Ruby &DSCL; start implicitly when the ror40 &DSCL; is started so that the user can only type scl enable ror40 command instead of scl enable ruby200 ror40 command to run command in the &DSCL; environment. + + + The ror40-scldevel subpackage is provided so that it is available in case you need it to build a &DSCL; which extends the ror40 &DSCL;. The package provides the %{scl_ror} and %{scl_prefix_ror} macros, which can be used to extend the ror40 &DSCL;. + + + Because the ror40 &DSCL;'s gems are installed in a separate root directory structure, you need to ensure that the correct ownership for the rubygems directories is set. This is done by using a snippet to generate a file list rubygems_filesystem.list. + + You are advised to set the runtime package to own all directories which would, if located in the root file system, be owned by another package. One example of such directories in the case of the ror40 &DSCL; is the Rubygem directory structure. + + + > %{buildroot}%{_scl_scripts}/enable << EOF +export PATH=%{_bindir}\${PATH:+:\${PATH}} +export LD_LIBRARY_PATH=%{_libdir}\${LD_LIBRARY_PATH:+:\${LD_LIBRARY_PATH}} +export MANPATH=%{_mandir}:\${MANPATH} +export PKG_CONFIG_PATH=%{_libdir}/pkgconfig\${PKG_CONFIG_PATH:+:\${PKG_CONFIG_PATH}} +export GEM_PATH=%{gem_dir}:\${GEM_PATH:+\${GEM_PATH}}\${GEM_PATH:-\`scl enable %{scl_ruby} -- ruby -e "print Gem.path.join(':')"\`} + +. scl_source enable %{scl_ruby} +EOF + +cat >> %{buildroot}%{_root_sysconfdir}/rpm/macros.%{scl_name_base}-scldevel << EOF +%%scl_%{scl_name_base} %{scl} +%%scl_prefix_%{scl_name_base} %{scl_prefix} +EOF + + +scl enable %{scl_ruby} - << \EOF +# Fake ror40 Software Collection environment. +GEM_PATH=%{gem_dir}:${GEM_PATH:+${GEM_PATH}}${GEM_PATH:-`ruby -e "print Gem.path.join(':')"`} \ +X_SCLS=ror40 \ +ruby -rfileutils > rubygems_filesystem.list << \EOR + # Create the RubyGems file system. + Gem.ensure_gem_subdirectories '%{buildroot}%{gem_dir}' + FileUtils.mkdir_p File.join '%{buildroot}', Gem.default_ext_dir_for('%{gem_dir}') + + # Output the relevant directories. + Gem.default_dirs[:%{scl}_system].each { |k, p| puts p } +EOR +EOF + +%files + +%files runtime -f rubygems_filesystem.list +%scl_files + +%files build +%{_root_sysconfdir}/rpm/macros.%{scl}-config + +%files scldevel +%{_root_sysconfdir}/rpm/macros.%{scl_name_base}-scldevel + + +%changelog +* Thu Jan 16 2014 John Doe - 1-1 +- Initial package.]]> +
+
+ The ror40-rubygem-bcrypt-ruby Package + Below is a commented example of the ror40-rubygem-bcrypt-ruby package spec file. This package provides the bcrypt-ruby gem. For more information on bcrypt-ruby, see the following website: + + + http://rubygems.org/gems/bcrypt-ruby + + + Note that the only significant difference between the ror40-rubygem-bcrypt-ruby package spec file and a normal &DSCL; package spec file is the following: + + + The BuildRequires tags are prefixed with %{?scl_prefix_ruby} instead of %{scl_prefix}. + + + - 3.1.2-4 +- Initial package.]]> +
+
+ Building the ror40 &DSCL; + To build the ror40 &DSCL;: + + + Install the ruby200-scldevel subpackage which is a part of Red Hat Software Collections. + + + Build ror40.spec and install the ror40-runtime and ror40-build packages. + + + Build rubygem-bcrypt-ruby.spec. + + +
+
+ Testing the ror40 &DSCL; + To test the ror40 &DSCL;: + + + Install the ror40-rubygem-bcrypt-ruby package. + + + Run the following command: + $ scl enable ror40 -- ruby -r bcrypt -e "puts BCrypt::Password.create('my password')" + + + Verify that the output contains the following line: + $2a$10$s./ReniLY.wXPHVBQ9npoeyZf5KzywfpvI5lhjG6Ams3u0hKqwVbW + + +
+
+
+ Extending the perl516 &DSCL; + This section describes extending the perl516 &DSCL; by building your own dependent &DSCL;. + + Examples described in this section only work as expected when extending the perl516 &DSCL; with packages that: + + + do not provide any Perl modules, and + + + only depend on Perl modules provided by the perl516 &DSCL;. + + + +
+ The h2m144 &DSCL; + This section contains a commented example of a dependent &DSCL;'s metapackage. The dependent &DSCL; is named h2m144 and contains the help2man Perl package version 1.44.1. The h2m144 &DSCL; depends on the perl516 &DSCL;. + Note the following in the h2m144 &DSCL; spec file: + + + The h2m144 &DSCL; spec file has the following build dependency set: + BuildRequires: %{scl_prefix_perl}scldevel + This expands to perl516-scldevel. + The perl516-scldevel subpackage contains two important macros, %scl_perl and %scl_prefix_perl, and also provides Perl dependency generators. Note that the macros are defined at the top of the spec file. Although the definitions are not required, they provide a visual hint that the h2m144 &DSCL; has been designed to be built on top of the perl516 &DSCL;. They also serve as a fallback value. + + + The h2m144-build subpackage has the following dependency set: + Requires: %{scl_prefix_perl}scldevel + This expands to perl516-scldevel. The purpose of this dependency is to ensure that the macros and dependency generators are always present when building packages for the h2m144 &DSCL;. + + + The enable scriptlet for the h2m144 &DSCL; contains the following line: + . scl_source enable %{scl_perl} + Note the dot at the beginning of the line. This line makes the Perl &DSCL; start implicitly when the h2m144 &DSCL; is started so that the user can only type scl enable h2m144 command instead of scl enable perl516 h2m144 command to run command in the &DSCL; environment. + + + The macro file macros.h2m144-config calls the Perl dependency generators, and certain Perl-specific macros used in other packages' spec files. + + + > %{buildroot}%{_scl_scripts}/enable << EOF +. scl_source enable %{scl_perl} +export PATH=%{_bindir}\${PATH:+:\${PATH}} +export MANPATH=%{_mandir}:\${MANPATH} +EOF + +cat >> %{buildroot}%{_root_sysconfdir}/rpm/macros.%{scl}-config << EOF +%%scl_package_override() %%{expand:%%global __perl_requires /usr/lib/rpm/perl.req.stack +%%global __perl_provides /usr/lib/rpm/perl.prov.stack +%%global __perl %{_scl_prefix}/%{scl_perl}/root/usr/bin/perl +} +EOF + +%files + +%files runtime +%scl_files + +%files build +%{_root_sysconfdir}/rpm/macros.%{scl}-config + +%changelog +* Tue Apr 22 2014 John Doe - 1-1 +- Initial package.]]> +
+
+ The help2man Package + Below is a commented example of the help2man package spec file. Note the following in the spec file: + + + The BuildRequires tags are prefixed with %{?scl_prefix_perl} instead of %{scl_prefix}. + + + /dev/null || : + +%preun +if [ $1 -eq 0 ]; then + /sbin/install-info --delete %{_infodir}/help2man.info \ + %{_infodir}/dir 2>/dev/null || : +fi + +%files -f %pkg_name.lang +%doc README NEWS THANKS COPYING +%{_bindir}/help2man +%{_infodir}/* +%{_mandir}/man1/* + +%if %{with nls} +%{_libdir}/help2man +%endif + +%changelog +* Tue Apr 22 2014 John Doe - 1.44.1-1 +- Built for h2m144 SCL.]]> +
+
+ Building the h2m144 Software Collection + To build the h2m144 &DSCL;: + + + Install the perl516-scldevel and perl516-perl-macros packages that are part of Red Hat Software Collections. + + + Build h2m144.spec and install the h2m144-runtime and h2m144-build packages. + + + Install the perl516-perl, perl516-perl-Text-ParseWords and perl516-perl-Getopt-Long packages, which are all build requirements for help2man. + + + Build help2man.spec. + + +
+
+ Testing the h2m144 Software Collection + To test the h2m144 &DSCL;: + + + Install the h2m144-help2man package. + + + Run the following command: + $ scl enable h2m144 'help2man bash' + + + Verify that the output is similar to the following lines: + .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.44.1. +.TH BASH, "1" "April 2014" "bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)" "User Commands" +.SH NAME +bash, \- manual page for bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu) +.SH SYNOPSIS +.B bash +[\fIGNU long option\fR] [\fIoption\fR] ... +.SH DESCRIPTION +GNU bash, version 4.1.2(1)\-release\-(x86_64\-redhat\-linux\-gnu) +.IP +bash [GNU long option] [option] script\-file ... +.SS "GNU long options:" +.HP +\fB\-\-debug\fR + + +
+
diff --git a/en-US/Introducing_Software_Collections.xml b/en-US/Introducing_Software_Collections.xml index ded0c2b..b837f3d 100644 --- a/en-US/Introducing_Software_Collections.xml +++ b/en-US/Introducing_Software_Collections.xml @@ -111,13 +111,15 @@
Installing a &DSCL; - To ensure that a &DSCL; is on your system, install the so-called metapackage of the &DSCL;. You can use conventional tools like Yum or PackageKit for this task because &DSCL;s are fully compatible with the RPM Package Manager. + To ensure that a &DSCL; is on your system, install the so-called metapackage of the &DSCL;. Thanks to &DSCL;s being fully compatible with the RPM Package Manager, you can use conventional tools like Yum or PackageKit for this task. For example, to install a &DSCL; with the metapackage named software_collection_1, run the following command: yum install software_collection_1 - This command will automatically install all the packages that are part of the &DSCL;. Also, if you install an application that depends on a &DSCL;, the &DSCL; will be installed along with the rest of the application's dependencies. + This command will automatically install all the packages in the &DSCL; that are essential for the user to perform most common tasks with the &DSCL;. + &DSCL;s allow you to only install a subset of packages you intend to use. For example, to use the Ruby interpreter from the ruby193 &DSCL;, you only need to install a package ruby193-ruby from that &DSCL;. + If you install an application that depends on a &DSCL;, that &DSCL; will be installed along with the rest of the application's dependencies. For detailed information on &DSCL; metapackages, see . diff --git a/en-US/Packaging_Software_Collections.xml b/en-US/Packaging_Software_Collections.xml index bcc36ba..47c0dbb 100644 --- a/en-US/Packaging_Software_Collections.xml +++ b/en-US/Packaging_Software_Collections.xml @@ -25,7 +25,7 @@ Create a &DSCL; metapackage - Each &DSCL; includes a metapackage, which installs a minimal subset of essential packages. See for more information on creating metapackages. + Each &DSCL; includes a metapackage, which installs a subset of the &DSCL;'s packages that are essential for the user to perform most common tasks with the &DSCL;. See for more information on creating metapackages. @@ -107,7 +107,7 @@ - the provider part, which defines the provider name, and + the provider part, which defines the provider's name, and @@ -118,8 +118,9 @@ These two parts of the &DSCL; prefix are separated by an underscore (_), as in the following example: myorganization_ruby193 - In this example, myorganization is the provider name, and ruby193 is the name of the &DSCL;. + In this example, myorganization is the provider's name, and ruby193 is the name of the &DSCL;. + While it is ultimately a vendor's or distributor's decision whether to specify the provider's name in the prefix or not, specifying it is highly recommended. A notable exception are &DSCL;s provided by Red Hat, they do not specify the provider's name in their prefixes.
&DSCL; Package Names @@ -158,7 +159,7 @@ Each &DSCL;'s layout consists of the metapackage, which installs a subset of other packages, and a number of the &DSCL;'s packages, which are installed within the &DSCL; namespace.
Metapackage - Each &DSCL; includes a metapackage, which installs a minimal subset of essential packages. For example, the essential packages can provide the Perl language interpreter, but no Perl extension modules. The metapackage contains a basic file system hierarchy and delivers a number of the &DSCL;'s scriptlets. + Each &DSCL; includes a metapackage, which installs a subset of the &DSCL;'s packages that are essential for the user to perform most common tasks with the &DSCL;. For example, the essential packages can provide the Perl language interpreter, but no Perl extension modules. The metapackage contains a basic file system hierarchy and delivers a number of the &DSCL;'s scriptlets. The purpose of the metapackage is to make sure that all essential packages in the &DSCL; are properly installed and that it is possible to enable the &DSCL;. The metapackage produces the following packages that are also part of the &DSCL;: @@ -166,6 +167,8 @@ The main package: %scl The main package in the &DSCL; contains dependencies of the base packages, which are included in the &DSCL;. The main package does not contain any files. + When specifying dependencies for your &DSCL;'s packages, ensure that no other package in your &DSCL; depends on the main package. The purpose of the main package is to install only those packages that are essential for the user to perform most common tasks with the &DSCL;. + Normally, the main package does not specify any build time dependencies (for instance, packages that are only build time dependencies of another &DSCL;'s packages). For example, if the name of the &DSCL; is myorganization_ruby193, then the main package macro is expanded to: myorganization_ruby193 @@ -186,6 +189,15 @@ myorganization_ruby193-build + + The scldevel subpackage: name-scldevel + + The scldevel subpackage in the %scl &DSCL; contains development files, which are useful when developing packages of another &DSCL; that depends on the %scl &DSCL;. The scldevel subpackage is optional and can be excluded from the %scl &DSCL;. + For example, if the name of the &DSCL; is myorganization_ruby193, then the scldevel subpackage macro is expanded to: + myorganization_ruby193-scldevel + For more information about the scldevel subpackage, see . + +
@@ -231,7 +243,7 @@ Example of the Metapackage To get an idea of what a typical &DSCL; metapackage looks like, see the following example: - %global scl software_collection + > %{buildroot}%{_scl_scripts}/enable << EOF export PATH=%{_bindir}\${PATH:+:\${PATH}} +export LD_LIBRARY_PATH=%{_libdir}\${LD_LIBRARY_PATH:+:\${LD_LIBRARY_PATH}} +export MANPATH=%{_mandir}:\$MANPATH +export PKG_CONFIG_PATH=%{_libdir}/pkgconfig\${PKG_CONFIG_PATH:+:\${PKG_CONFIG_PATH}} EOF -%scl_install + +cat >> %{buildroot}%{_root_sysconfdir}/rpm/macros.%{scl_name_base}-scldevel << EOF +%%scl_%{scl_name_base} %{scl} +%%scl_prefix_%{scl_name_base} %{scl_prefix} +EOF + +# Install the generated man page +mkdir -p %{buildroot}%{_mandir}/man7/ +install -p -m 644 %{scl_name}.7 %{buildroot}%{_mandir}/man7/ %files @@ -279,9 +309,12 @@ EOF %files build %{_root_sysconfdir}/rpm/macros.%{scl}-config +%files scldevel +%{_root_sysconfdir}/rpm/macros.%{scl_name_base}-scldevel + %changelog * Fri Aug 30 2013 John Doe <jdoe@example.com> 1-1 -- Initial package +- Initial package]]>
Converting a conventional spec file into a &DSCL; spec file diff --git a/en-US/Preface.xml b/en-US/Preface.xml index 20c17ac..2ff659c 100644 --- a/en-US/Preface.xml +++ b/en-US/Preface.xml @@ -9,7 +9,7 @@
Acknowledgments - The author of this book would like to thank the following people for their valuable contributions: Jindřich Nový, Marcela Mašláňová, Bohuslav Kabrda, Honza Horák, Jan Zelený, Martin Čermák, Langdon White, Florian Nadge, Stephen Wadeley, Douglas Silas, Tomáš Čapek, and Vít Ondruch, among many others. + The author of this book would like to thank the following people for their valuable contributions: Jindřich Nový, Marcela Mašláňová, Bohuslav Kabrda, Honza Horák, Jan Zelený, Martin Čermák, Jitka Plesníková, Langdon White, Florian Nadge, Stephen Wadeley, Douglas Silas, Tomáš Čapek, and Vít Ondruch, among many others.
diff --git a/en-US/Software_Collections_Guide.xml b/en-US/Software_Collections_Guide.xml index 7c6ae82..b46af21 100644 --- a/en-US/Software_Collections_Guide.xml +++ b/en-US/Software_Collections_Guide.xml @@ -12,8 +12,10 @@ xmlns:xi="http://www.w3.org/2001/XInclude" /> - + + + + + Troubleshooting &DSCL;s + This chapter helps you troubleshoot some of the common issues you can encounter when building your &DSCL;s. +
+ Error: line <replaceable>XX</replaceable>: Unknown tag: %scl_package <replaceable>software_collection_name</replaceable> + You can encounter this error message when building a &DSCL; package. It is usually caused by a missing package scl-utils-build. To install the scl-utils-build package, run the following command: + # yum install scl-utils-build + For more information, see . +
+
+ scl command does not exist + This error message is usually caused by a missing package scl-utils. To install the scl-utils package, run the following command: + # yum install scl-utils + For more information, see . +
+
+ Unable to open /etc/scl/prefixes/<replaceable>software_collection_name</replaceable> + This error message can be caused by using incorrect arguments with the scl command you are calling. Check the scl command is correct and that you have not mistyped any of the arguments. + The same error message can also be caused by a missing &DSCL;. Ensure that the software_collection_name &DSCL; is properly installed on the system. For more information, see . +
+
+ scl_source: command not found + This error message is usually caused by having an old version of the scl-utils package installed. To update the scl-utils package, run the following command: + # yum update scl-utils +
+