PACKAGE Lines
The purpose of the PACKAGE line is to support two different needs:
| • | To license a product SUITE, or |
| • | To provide a more efficient way of distributing a license file that has a large number of features, which largely share the same FEATURE line arguments. |
A PACKAGE line, by itself, does not license anything—it requires a matching feature definition line to license the whole package. A PACKAGE line is shipped by your software publisher with a product, independent of any licenses. Later, when you purchase a license for that package, one or more corresponding feature definition lines enable the PACKAGE line.
Example
PACKAGE package vendor [pkg_version] COMPONENTS=pkg_list \
[OPTIONS=SUITE] [SUPERSEDE[="p1 p2 ..."] ISSUED=date]
SIGN="<...>"
The following lists the PACKAGE line fields. They must appear in the order listed.
|
Field |
Description |
|
package |
Name of the package. The corresponding feature definition line must have the same name. |
|
vendor |
Name of the vendor daemon that supports this package. |
|
pkg_version |
Provide the version of the package. The corresponding feature definition line must have the same version. |
|
COMPONENTS=pkg_list |
List of package components. The format is: feature[:version[:num_lic]] Packages must consist of at least one component. Version and count are optional, and if left out, their values come from the corresponding feature definition line. num_lic is only legal if OPTIONS=SUITE is not set—in this case the resulting number of licenses is num_lic on the COMPONENTS line multiplied by the number of licenses in the feature definition line. Examples: COMPONENTS="comp1 comp2 comp3 comp4" |
|
Optional field. Used to denote a package suite. If set, the corresponding feature of the same name as the package is checked out in addition to the component feature being checked out. If not set, then the corresponding feature of the same name as the package is removed once the package is enabled; it is not checked out when a component feature is checked out. |
|
|
Optional field. If set, reserves a set of package components. Once one package component is checked out, all the other components are reserved for that same user. |
|
|
SUPERSEDE |
Optional field. Used in conjunction with ISSUED date. Replaces all PACKAGE lines for the same package name with previous or no ISSUED dates. |
|
ISSUED= |
Optional field. Used in conjunction with SUPERSEDE in the PACKAGE line. Replaces all PACKAGE lines for the same package name with previous or no ISSUED dates. |
|
or |
SIGN= signature to authenticate this FEATURE line. If your publisher has deployed his vendor daemon using the common vendor daemon technology, signatures are embedded within the AUTH= keyword. Contact your publisher for further details. |
Examples
PACKAGE suite sampled 1.0 SIGN="<...>" \
COMPONENTS="comp1 comp2" OPTIONS=SUITE
FEATURE suite sampled 1.0 31-dec-2020 5 SIGN="<...>"
This is a typical OPTIONS=SUITE example. There are two features, “comp1” and “comp2,” which are each version 1.0, each with five licenses available. When “comp1” or “comp2” is checked out, “suite” is also checked out.
PACKAGE suite sampled 1.0 SIGN="<...>"\
COMPONENTS="apple:1.5:2 orange:3.0:4"
FEATURE suite sampled 1.0 31-dec-2020 3 SN=123 SIGN="<...>"
In this example, the component version overrides the feature version, and the number of licenses available for any component is the product of the three licenses for “suite” and the number of licenses for that component. The result is equivalent to:
FEATURE apple sampled 1.5 31-dec-2020 6 SN=123 SIGN="<...>"
FEATURE orange sampled 3.0 31-dec-2020 12 SN=123 SIGN="<...>"
Note:The following lists changes to PACKAGE lines:
| • | Ability to store PACKAGE lines in separate files introduced in version 6 client library. |
| • | pkg_version field required is mandatory. |
| • | AUTH keyword introduced in version 10.8 client library and vendor daemon. |