Bug 1180638
| Summary: | Document creating software collections for scl-utils-2.0 | ||
|---|---|---|---|
| Product: | Red Hat Software Collections | Reporter: | Ľuboš Kardoš <lkardos> |
| Component: | doc-Packaging_Guide | Assignee: | Petr Kovar <pkovar> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | high | ||
| Version: | unspecified | CC: | jberan, jhradile, jorton, jzeleny, kanderso, pkovar |
| Target Milestone: | rc | ||
| Target Release: | 2.2 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-12-15 07:32:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1159032 | ||
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 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. |
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