Dependencies between Software Packages

With DSM you can create revisions for packages which you can use for saving minor changes to package files and package configurations and for assigning them to specific targets. However, if you want to create dependencies between different packages, revisions do not help. DSM provides other solutions for creating these dependencies.

Packages that replace one another ('Replacement ID')

To replace a software package with a new version or a completely different software, you usually create a brand new package rather than a new revision.

Example:

Acrobat Reader 8 is installed on a certain number of computers.
You want to install Acrobat Reader 9 on some of these computers.
In order to install Acrobat Reader 9, Acrobat Reader 8 has to be uninstalled.
Both AutoInstall and the Software Shop should cover this procedure.

To support this type of scenario, DSM provides the new package property Replacement ID; with this property you can identify packages which are mutually exclusive (or mutually supportive) and also allow an upgrade (or downgrade) from one to another package.
In general, packages with the same Replacement ID behave in the same way as a single package that has several revisions.

Note the following points when using a Replacement ID:

You cannot install the respective packages on the same computer at the same time.
When you update the respective policies, you can select the revisions of the other package as well.
When you copy a package, you can specify a Replacement ID for both packages.

The following applies to Replacement IDs:

String with maximum 32 characters.
Valid characters: A-Z, a-z, 0-9 and '_'.
Capitalization is ignored.
The first character must be A-Z or a-z.
The default is empty.
The ID is always uniform for all revisions of a package.
You can only change an existing ID if there are no other packages with the same ID and existing policies.
There are no Replacement IDs for Software Sets and for packages where the setting Allow multiple execution is active.

Packages that depend on another specific package ('Software Tags').

Software packages depend on each other in a completely different way if one package is used to install a specific software (e.g. an internet browser) and the other packages contain the corresponding Add-Ins.
In order to update the browser it may be necessary to update all of the corresponding Add-Ins as well.

Example:

AutoCAD is installed on a certain number of computers.
In addition, different AutoCAD plugins are installed, too.
You want to update AutoCAD with a new version.
All of the AutoCAD plugins have to be reinstalled.

To support this type of scenario, DSM has the following solution: You can assign as many software tags as you like to the packages and then use these tags in eScripts for running the commands ChangeSWAssignment and MarkPackageAsNotInstalled.
In the AutoCAD example, all of the AutoCAD plugins get the same software tag. You insert the ChangeSWAssignment command in the AutoCAD script which reinstalls all packages that have the software tag of the respective plugins when AutoCAD is updated.

The following applies to software tags:

List of strings with maximum 32 characters.
Valid characters: A-Z, a-z, 0-9 and '_'.
Capitalization is ignored.
The first character must be A-Z or a-z.
The default is empty.
The software tag is always uniform for all revisions of a package.
You can only change an existing software tag if there are no other packages with the same software tag and existing policies.
There are software tags for all kinds of packages and Software Sets for dynamic software categories.