SupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

2.7. Package Layout

Each Software Collection's layout consists of the metapackage, which installs a subset of other packages, and a number of the Software Collection's packages, which are installed within the Software Collection namespace.

2.7.1. Metapackage

Each Software Collection includes a metapackage, which installs a subset of the Software Collection's packages that are essential for the user to perform most common tasks with the Software Collection. 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 Software Collection's scriptlets.
The purpose of the metapackage is to make sure that all essential packages in the Software Collection are properly installed and that it is possible to enable the Software Collection.
The metapackage produces the following packages that are also part of the Software Collection:
The main package: %name
The main package in the Software Collection contains dependencies of the base packages, which are included in the Software Collection. The main package does not contain any files.
When specifying dependencies for your Software Collection's packages, ensure that no other package in your Software Collection 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 Software Collection.
Normally, the main package does not specify any build time dependencies (for instance, packages that are only build time dependencies of another Software Collection's packages).
For example, if the name of the Software Collection is myorganization-ruby193, then the main package macro is expanded to: 
myorganization-ruby193
The runtime subpackage: %name-runtime
The runtime subpackage in the Software Collection owns the Software Collection's file system and delivers the Software Collection's scriptlets. This package needs to be installed for the user to be able to use the Software Collection.
For example, if the name of the Software Collection is myorganization-ruby193, then the runtime subpackage macro is expanded to: 
myorganization-ruby193-runtime
The build subpackage: %name-build
The build subpackage in the Software Collection delivers the Software Collection's build configuration. It contains RPM macros needed for building packages into the Software Collection. The build subpackage is optional and can be excluded from the Software Collection.
For example, if the name of the Software Collection is myorganization-ruby193, then the build subpackage macro is expanded to: 
myorganization-ruby193-build
The contents of the myorganization-ruby193-build subpackage are shown below: 
$ cat /etc/rpm/macros.ruby193-config
%scl myorganization-ruby193
The syspaths subpackage: %name-syspaths
The syspaths subpackage in the Software Collection provides an optional way to install convenient shell wrappers and symbolic links into the standard path, thus altering the base system installation, but making binary files in the Software Collection packages easier to use.
For example, if the name of the Software Collection is myorganization-ruby193, then the syspaths subpackage macro is expanded to: 
myorganization-ruby193-syspaths
For more information about the syspaths subpackage, see Section 3.3, “Providing syspaths Subpackages”.
The scldevel subpackage: %name-scldevel
The scldevel subpackage in the %name Software Collection contains development files, which are useful when developing packages of another Software Collection that depends on the %name Software Collection. The scldevel subpackage is optional and can be excluded from the %name Software Collection.
For example, if the name of the Software Collection is myorganization-ruby193, then the scldevel subpackage macro is expanded to: 
myorganization-ruby193-scldevel
For more information about the scldevel subpackage, see Section 4.1, “Providing an scldevel Subpackage”.

2.7.2. Creating a Metapackage

When creating a new metapackage:

  • Define the following macros at the top of the metapackage spec file, above the %scl_package macro:
    • scl_name_prefix that specifies the provider's name to be used as a prefix in your Software Collection's name, for example, myorganization-. This is different from _scl_prefix, which specifies the root of your Software Collection but also uses the provider's name. See Section 2.4, “The Software Collection Prefix” for more information.
    • scl_name_base that specifies the base name of your Software Collection, for example, ruby.
    • scl_name_version that specifies the version of your Software Collection, for example, 193.
  • You are advised to define a Software Collection macro nfsmountable that changes the location of configuration and state files and makes your Software Collection usable over NFS. For more information, see Section 3.1, “Using Software Collections over NFS”.
  • Consider specifying all packages in your Software Collection that are essential for the Software Collection run time as dependencies of the metapackage. That way you can ensure that the packages are installed with the Software Collection metapackage.
  • You are advised to add Requires: scl-utils-build to the build subpackage.
  • You are not required to use conditionals for Software Collection-specific macros in the metapackage.
  • Include any path redefinition that the packages in your Software Collection may require in the enable scriptlet.
    For information on commonly used path redefinitions, see Section 2.9, “Commonly Used Path Redefinitions”.
  • Always make sure that the metapackage contains the %setup macro in the %prep section, otherwise building the Software Collection will fail. If you do not need to use a particular option with the %setup macro, add the %setup -c -T command to the %prep section.
    This is because the %setup macro defines and creates the %buildsubdir directory, which is normally used for storing temporary files at build time. If you do not define %setup in your Software Collection packages, files in the %buildsubdir directory will be overwritten, causing the build to fail.
  • Add any macros you need to use to the macros.%{scl}-config file in the build subpackage.

Example of the Metapackage

To get an idea of what a typical metapackage for a Software Collection named myorganization-ruby193 looks like, see the following example: 
%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}

# Optional but recommended: define nfsmountable
%global nfsmountable 1

%global _scl_prefix /opt/myorganization
%scl_package %scl

Summary: Package that installs %scl
Name: %scl_name
Version: 1
Release: 1%{?dist}
License: GPLv2+
Requires: %{scl_prefix}less
BuildRequires: scl-utils-build

%description
This is the main package for %scl Software Collection.

%package runtime
Summary: Package that handles %scl Software Collection.
Requires: scl-utils

%description runtime
Package shipping essential scripts to work with %scl Software Collection.

%package build
Summary: Package shipping basic build configuration
Requires: scl-utils-build

%description build
Package shipping essential configuration macros to build %scl Software Collection.

# This is only needed when you want to provide an optional scldevel subpackage
%package scldevel
Summary: Package shipping development files for %scl

%description scldevel
Package shipping development files, especially useful for development of
packages depending on %scl Software Collection.

%prep
%setup -c -T

%install
%scl_install

cat >> %{buildroot}%{_scl_scripts}/enable << EOF
export PATH="%{_bindir}:%{_sbindir}\${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

# This is only needed when you want to provide an optional scldevel subpackage
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

%files runtime -f filelist
%scl_files

%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 &lt;jdoe@example.com&gt; 1-1
- Initial package
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.