First some general comments. It is important to note that much of the information about which package version works with what other package version, is contained in the release directory structure itself. This removes the requirement that this information be stored in the UPS database as dependencies. This is desirable for a number of reasons. Maintaining and distributing this information in the form of the UPS database has through the years proven to be difficult. Various recent additions to UPS help - cups is an example - but it is still true that you must be a UPS expert in order to effectively maintain this information. In a period of stable code distributions this is not a disaster; however, in a heavy development period it may become one. The other reason for minimizing UPS's knowledge of package dependencies is that it will speed up and simplify the process of setting up a set of packages. There will be fewer ambiguities about which versions of packages actually get setup.
However the concept of UPS product dependencies is still needed. There are
many products that we use, over
which we have little or no control. In fact any
package for which we do not keep
our own CVS library, would be classified in this category. Let's call
them external packages. Examples
would be products like cernlib or tcl/TK. These packages do not live in the
directory structure,
and therefore the older mechanisms for handling dependencies are still required.
Hopefully the coupling between
this class of packages is not strong. For instance, no one would be happy if
you could only use version A of
tcl/Tk with version B of cernlib. Also, note that references to libraries and
binaries from this class of package are still referred to through environmental
variables or path setting. They are not copied to the
$SRT\_DIST/release/<version>/lib or $SRT\_ROOT/release/<version>/bin areas.