Last modified 10 years ago Last modified on 06/02/2009 07:39:11 PM

DC3a Post Mortem Meeting

Build and Packaging System Break-out

This page will be used to capture notes and actions from the break out session during the May 2009 meeting in Tucson.


EUPS is a package we use to manage the installation and use of many software products--both LSST-developed packages and 3rd-party products--in an integrated environment to run LSST applications, including LSST pipelines. An important feature that sets it apart from other commonly use package managers (e.g. rpm, apt) is that it allows multiple versions to be installed simultaneously. Interactive runtime (as opposed to install-time) user tools allow a user to flexibly switched between different versions of desired products and to have all the products it depends on to be automatically loaded into the environment. Another unusual feature is that EUPS gives the user broad control over what packages are manged by EUPS and where they are installed.

EUPS provides a way to distribute products (and all their dependencies) from package distribution servers. In LSST, the main server is at When ever possible, packages are distributed in source and built on a user's local platform when requested. This is done via a user tool call lsstpkg that is a thin wrapper around the eups distrib tool; the former ensures that LSST-specific enhancements (the lssteups package) are used. More details describing our use of EUPS can be found in our Getting Started document.

As part of the wrap up to DC2, a discussion of EUPS features and recommended changes began. K-T Lim and Russell Owen detailed a number of suggestions. This led to a proposal by Robert Lupton captured in wiki:TCTPackageProposal. (This is still somewhat incomplete.) Some of the proposed behavior has been implemented but not yet incorporated into the current LSST build environment.


platforms and compilers (see changes to agenda)


  • Using default policies
    • policy validation is largely in place; need to finish
    • need example for proper loading of default policies
    • make it an error to load a Dictionary as a policy that overrides another Dictionary

version numbering

  • adopt a more rigorous version numbering practice