Bug 1180638 - Document creating software collections for scl-utils-2.0
Summary: Document creating software collections for scl-utils-2.0
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Software Collections
Classification: Red Hat
Component: doc-Packaging_Guide
Version: unspecified
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: 2.2
Assignee: Petr Kovar
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1159032
TreeView+ depends on / blocked
 
Reported: 2015-01-09 15:43 UTC by Ľuboš Kardoš
Modified: 2020-12-15 07:32 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-15 07:32:41 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Ľuboš Kardoš 2015-01-09 15:43:31 UTC
Description of problem:
A new version of scl-utils (scl-utils-2.0) was released. This new version of scl-utils is backward compatible with old scl-utils, it can handle collections builded for old scl-utils. But scl-utils-2.0 also suppports a new type of collections and for these new collections scl-utils-2.0 provides some additional commands. It is necessary to document how to build collections of this new type with scl-utils-build-2.0.

The main difference is that runtime packages of new collections have to contain one additional file. This file is module file. Its purpose is the same as the purpose of the enable script. The enable script has to be still included in the runtime package because of compatibility. But it can be created automatically from module file.

* Building collection for new scl-utils *
----------------------------------------
The new version of scl-utils uses environment modules. So it requires software
collections to contain module file in scl runtime package. Module files are
very similar to enable scripts. Have a look at following examples:

Simple creation of an enable script in spec of metapackage looks like this:

cat >> %{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

And creation of the simplest modulefile with the same functionality would look
like this:

cat >> %{buildroot}%{_scl_scripts}/%{scl} << EOF
#Module1.0
prepend-path    X_SCLS              %{scl}
prepend-path    PATH                %{_bindir}
prepend-path    LD_LIBRARY_PATH     %{_libdir}
prepend-path    MANPATH             %{_mandir}
prepend-path    PKG_CONFIG_PATH     %{_libdir}/pkgconfig
EOF
#automaticaly create enable script for compatibility
%scl_enable_script

All variables that are set in enable script have to be set also in module file.
But there is a new variable in module file variable X_SCLS. This variable was 
used in the previous version of scl for storing names of enabled collections
and it was set automatically. Some people depend on this variable. The new
version of scl uses environment modules that have own variable with different
name for this purpose. If we don't want to patch enviroment modules then adding
variable X_SCLS to module file is the simplest way how to maintan backward
compatibility.

For more info about module files man 4 modulefile

Comment 3 Robert Kuska 2015-11-26 10:27:47 UTC
man 4 modulefile shows #%Module1.0 not #Module1.0

Using #Module1.0 scl enable fails with:

Collection 'foo' doesn't exist.

Further examination shows:

Magic cookie '#%Module' missing in

Comment 7 RHEL Program Management 2020-12-15 07:32:41 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.


Note You need to log in before you can comment on or make changes to this bug.