Package header

The package header contains the component name in each of the supported languages, the UID of the package, the major and minor version number and build number, and package options.

The syntax for a package-header item is as follows:

#{"Component name for language 1", ...}, (package-uid), major, minor, build-number[, package-options, ...]

• package-options

  • package-type

• Example

• Notes

In the package-header statement, package-options may be any of the following:

Abbreviation Name Description TYPE=package-type Specifies the package-type that identifies the purpose of the package IU IUNICODE This flag is obsolete and is ignored. Package file is in Unicode format. SH SHUTDOWNAPPS Shuts down all applications on the device. Software Install terminates running applications on the device as needed during the installation process, so the use of this flag is not now recommended. NC NOCOMPRESS Files will not be compressed within the SIS file

In the package-options above, package-type may be any of the following:

Abbreviation Name Description SA SISAPP A package containing an application (the default type). SP SISPATCH A package that patches an existing component. It may be removed by the user. PU PARTIALUPGRADE This is a variation of SA in that files present in the original package now missing in the upgrade package are not removed.

Note that these options are mutually exclusive - only one option is valid per SIS file. Note that options SO, SC, SY and SU are no longer supported.

Notes on upgrading packages

When installing a package with the SA package type, and that package has already been installed, the user will be given the choice of replacing the existing installation entirely, or cancelling the installation.

Note that if the user chooses to continue, any private directories owned by the application will be deleted. Note also that any files that were listed in the original installation with the FILENULL option, will not be removed.

Software Install additionally supports partial upgrades, indicated by the PU package-type. A partial upgrade cannot remove any files; it can only add or overwrite files. This allows a small upgrade SIS to replace just the parts of a package which require replacement, and not re-deliver the whole package.

Unlike packages installed using the SA or SP options, a partial upgrade package is not listed as a removable component after installation, so the user needs to remove or reinstall the associated application to remove the changes.

When specifying a PU package, the drive selection dialog should be suppressed, so that the install drive will be the one associated with the existing package. This means that new files get installed to the same drive and not one arbitrarily chosen by the user. Clearly, if space is limited on this drive, the upgrade cannot continue.

A patch (specified using the SP package type) differs from a partial upgrade in that it can only add new files; it cannot overwrite existing files, and it is uninstallable.

The following is an example of a package header item:

#{"MyApp-EN", "MyApp-FR", "MyApp-Zulu"}, (0x1000001F), 1, 2, 3, TYPE=SA

• The package type information is to be used for the following purposes:

  • Allows the user to easily identify the main installed applications, distinct from any system components.

  • Allows the add/remove control panel item to distinguish the packages which the user may not remove. For example a PARTIALUPGRADE package is designed to upgrade an existing package and cannot be removed without removing the entire component which was upgraded. Upgrade components (PARTIALUPGRADE) are not listed in the add/remove list as removable components.

• All package files require a UID, even if the installed components do not strictly require one. It is used to identify packages when installing, upgrading and removing.

  • The UID value specified in an application's (SISAPP) package header must be unique. It uniquely identifies the SIS file, and is never the same as the application's UID.

  • The package UID is allocated in the same way as an application's 3rd UID, through https://www.symbiansigned.com. The process is described here.

  • The UID for the following types of SIS files may be identical to the UID for the main app or system component with which they are associated:

    • Patches (SISPATCH)

    • Upgrade components (PARTIALUPGRADE)

• The application's major and minor version numbers are required for version control (e.g., AppName 3.1 specifies a major build 3, and minor build 1.)

• The build-number replaces the variant value which was unimplemented in previous versions of MakeSIS.

• All numbers can be hexadecimal.

• The component name is language dependent. It is used to identify the component in the installation dialogs and in the list of installed programs in the control panel's Add\remove program.

• The number of component names must equal the number of languages specified in the languages line, and should be in the same order.

• Where previous versions of MakeSIS only supported two letter abbreviations, the new version supports longer variants of the same options. This applies in general for all PKG statements.

• With previous versions of MakeSIS there was an unpublished "ID" flag that was intended to indicate the SIS file was "distributable". Whilst this flag could appear in a PKG file, it served no purpose and was ignored by the install software, and thus has now been dropped.