When you modify a package, perhaps to apply a new signing certificate, you should add a value to the
version number, for example, -b (9.00.1399.06-b) to indicate this is a later package version than the
9.00.1399.06 version.
Add this version with the same care you use with the UpstreamVersion. If you use non-numeric
characters, they are processed as a string as described in the UpstreamVersion. The following list is an
example, lowest to highest version.
9.00.1399.06-A (earlier version)
9.00.1399.06-B
9.00.1399.06-a
9.00.1399.06-b (later version)
A full version may look like the following example: 10;10.0.1600.22-b, where 10 is the Epoch,10.0.1600.22 is
the UpstreamVersion, and b is the Version (a package version rather than an application version).
How Package Names and Versions Are Processed by Package Manager
When the command to install a package is issued to Package Manager, it evaluates packages for the name
and for the version based on the operator (=; <; >; <=; >=). The Package Manager checks the Control.xml
file in the *.crate file for the Crate Name and the Version.
For example, a package identified as sqlserver, version 8.0-a, has been installed by the Package Manager.
You issue a command to install "sqlserver >= 9.00.1399.06". Package Manager reviews its list of known
software packages and determines that sqlserver, version 8.0-a is already installed. It then reviews the
known repository sources and identifies available packages sqlserver, version 9.00.1399.06, and sqlserver,
version 9.00.1399.06-b. It installs the highest version of which it is aware, in this example, sqlserver version
9.00.1399.06-b.
Project Naming, Package Naming, and Package File Naming
It is possible to have the published package file name (.crate) be different from the suggested package file
name, which is the package name as it appears on the package Properties tab, along with the version and
architecture. This is usually as the result of the user changing the name of the package file from the
suggested name when generating in Package Studio.
For example, you begin creating a new sqlserver package for 10.0.1600.22 (SQL Server 2008), where the
Properties
tab
Name
is sqlserver, and you save the project as sqlserver2008.prj. You continue working on
the project, adding command arguments and pre- and post-command scripts. When it is ready to go into
production, you
Generate
the package, changing the suggested file name, as it appears in the
Generate
Software Package for Windows
dialog box to prod-sqlserver_10.0.1600.22_x86.crate so you can identify
the production-ready version. The next day you are publishing this and other production-ready packages
to a repository. You click
Publish > Existing
and select your existing prod-sqlserver_10.0.1600.22_x86.crate
file. You then complete the process of publishing it to the repository. The file is published to the
repository\crates\s folder, but with a file name of prod-sqlserver_10.0.1600.22_x86.crate. However, the
control.xml file contains the correct Crate Name, sqlserver, and the package is still processed by Package
Manager as sqlserver, version 10.0.1600.22, x86 architecture.
Creating Packages
A software package provides the files and metadata necessary to install and remove programs. One of the
most useful features of a package is the metadata regarding dependencies, conflicts, and other
relationships that are not represented by software installation files. This metadata is used to determine if
the necessary dependencies are in place so that an installation is successful, and if not, what is necessary to
make the installation successful. This use of metadata is similar to rpm on Linux.
Using Package Studio to Create Software Packages and Publish to Repositories
VMware, Inc.
23
