Upgrading rules in Software Installation Toolkit

Summary

Type	Package UID	Package name	Version	Global vendor name	Notes
`SA`	Same	Same	Higher (not mandatory)	Same	Can overwrite (replace) files
`SP`	Same	Different	Doesn't matter	Doesn't matter	Can't overwrite (replace) files
`PU`	Same	Doesn't matter	Higher (not mandatory)	Doesn't matter	Can overwrite (replace) files

Details

SA

When upgrading using a package of type SA, the original package is entirely replaced by the new one. Any files not re-delivered by the new package are removed from the device. After the upgrade has completed, the new package cannot be removed separately from the original; to remove the upgrade, the entire package must be removed.

RR and RB executables in the base package are run during the upgrade.

If the upgrade causes an executable to be removed, the corresponding private directory is deleted. Any directories and files that were created by the application outside of its private directory are not removed. It is the responsibility of the application to clean these up. It is therefore recommended that files created by an application should be located in the application's private directory.

If the upgrade causes an executable to be replaced, the private directory is untouched.

The version number of the upgrading package should be higher than that of the original. To be identified as an upgrade, the upgrading package file must have the same package UID, global vendor name, and package name as the original. If the package UID differs, then it will be considered to be an unrelated package, not an upgrade. If the package UID is the same but the vendor name or package name differs, then the installer will report an error.

When upgrading a package of type SA by another SA and the package being upgraded has been patched (see next bullet point), the patch will not be uninstalled by the upgrade.

An upgrading package of type SA cannot overwrite files installed by a patch. For such a package to install, the patch would first need to be uninstalled.
SP

A patch, specified using the SP package type, is an augmentation to an existing package (the "base package"), for instance additional levels for a game.

A patch differs from a partial upgrade (see the next bullet point) in that it can only add files to a base package; it cannot overwrite files, and it can be uninstalled separately from the base package. If a patch tries to modify or replace an existing file in the base package, the installation will fail.

If two patches with the same package name and UID are installed, the second patch is treated as an upgrade of the first patch and will replace it entirely.

The patch's package UID must be the same as the base package's UID, but it should have a different package name. The patch can have its own version number.
PU

A partial upgrade, indicated by the PU package-type, is a variation of SA in that any files present in the base package that are missing from the upgrading package are not removed. A partial upgrade can only add or overwrite files. This allows an upgrading SIS to replace just the parts of a base package which require replacement, and not re-deliver the whole package.

RR and RB executables in the base package are run during the upgrade.

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 and reinstall the base package to remove the changes.

When creating a PU package, the drive selection dialog should be suppressed, so that the upgrade will be installed to the same drive as the existing package and not one arbitrarily chosen by the user. Clearly, if space is limited on this drive, the upgrade cannot continue.

The package UID for a partial upgrade must be the same as the base package's, but the package names do not need to match. The version number should increment.

A partial upgrade cannot overwrite files installed by a patch.