Some packages are optional. They are needed for a specific site or for specific functionality that is not widely used. In order to reduce the number of packages that most people must install these are made optional.

Optional externals and dybinst

The dybinst install script now has a step called "optional" that is normally run after "externals" or can be run by hand

dybinst <RELEASE> optional [<list of optional packages>]

If the list of packages are not given, an internally hard coded list will be considered.

Determining if an optional is desired

An optional package will be installed if a certain CMT tag exists from the context of the DybRelease package. The tag formed using the package name like:

build_optional_<package>

Optional dybgaudi packages

If one writes a dybgaudi package which depends on an optional external, it too must be made optional. This can be done by applying a pattern from LCG_Settings in any package needing this optional package (such as release packages). Where normally you would write in say, TheHatRelease/cmt/requirements:

use AnOptionalPackage v* TheHat

you would instead write

apply_pattern use_optional pkg=AnOptionalPackage useopts="v* TheHat"

If one of the following tags exist then AnOptionalPackage will be used:

TheHatRelease_use_AnOptionalPackage
TheHatRelease_use_all
use_AnOptionalPackage
USE_ALL_OPT_PKG

Or, more generally if <package> is the package that wants to use the optional package <pkg> then any one of these tags will cause that to happen:

 <package>_use_<pkg>
 <package>_use_all
 use_<pkg>
 USE_ALL_OPT_PKGS

Using optional external packages

Such a package would declare the need for an optional external in a similar manner. Instead of

use OptionalExternal v* LCG_Interfaces

one would write

apply_pattern use_optional_interface pkg=OptionalExternal

As a side effect, this pattern will define the magic tag described above:

build_optional_OptionalExternal

How to best configure a site for optional packages

Finally, a way is needed to inject the tags needed to say which optional packages are desired for a certain site. The best way to do this through special packages pointed to by the CMTHOME and CMTUSERCONTEXT environment variables and then have all users set the variables to point to the package directories. Then, in

$CMTUSERCONTEXT/requirements

one can apply tags like

apply_tag use_AnOptionalPackage

Even better with nuwaenv

Sites using nuwaenv can set these variables using either the pre_env or post_env parameters. Details can be found in the topic on nuwaenv.

Examples

The package that drove this development was Rafiman which needs django. Rafiman is introduced to NuWa through the hat release package UtilitilesRelease which has its requirements file at

dybgaudi/Utilities/UtilitiesRelease/cmt/requirements

In there you can find

apply_pattern use_optional pkg=Rafiman useopts="v* Utilities"

Then in the Rafiman requirements file there is

apply_pattern use_optional_interface pkg=django

which sets build_optional_django.

The $CMTHOME/requirements file is empty (see this topic for why) and the $CMTUSERCONTEXT/requirements file contains

apply_tag use_Rafiman

Finally, at RACF or other sites using nuwaenv the users gain all this configuration automatically as the ~dayabay/.nuwaenv.cfg file has

[defaults]
...
pre_env = ['set CMTUSERCONTEXT=~dayabay/racf/cmtusercontext',
           'set CMTHOME=~dayabay/racf/cmthome']