Installing Optional External Packages

From Daya Bay

Jump to: navigation, search

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:


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:


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:


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:


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


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.


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


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

pre_env = ['set CMTUSERCONTEXT=~dayabay/racf/cmtusercontext',
           'set CMTHOME=~dayabay/racf/cmthome']
Personal tools