Next Previous Contents

5. SLP Identification, Dependency, and Security Mechanisms

5.1 Unique Package Identifiers

Each SLP file has a set of unique identifiers, which are not shared with any other package. Unique package identifiers fall into three categories: system identifiers, software identifiers and release identifiers.

System Identifiers

System identifiers delineate the required environment for proper package installation. The SLPv5a specification defines these identifiers to be distribution identifier, distribution release, binary format.

The distribution identifier (delineated by the DistributionMagicNumber field) provides a mechanism to differentiate between various distinct projects which use the SLP format. Packages are keyed against a specific distribution due to the wide variety of differences between distributions: initscript type, filesystem standard compliance, package content policies, stock user and group information, as well as package offerings. Distribution identifiers are provided by a central authority, to prevent conflicting identifier use.

The distribution release identifier (delineated by the DistributionReleaseIndex field) provides a mechanism for distributions to differentiate between incompatible stable, development and experimental package releases. Values for this field are assigned by a distribution and are tracked by the distribution internally. Through the use of this field, packages are keyed against a specific distribution release, preventing possible issues due to change in core system libraries, such as glibc, or other significant changes. Keying of packages against a specific distribution release also enables a distribution's support staff to more suitably recommend software upgrade compatibility.

The binary format identifier (delineated by the SoftwareBinaryFormat field) provides a mechanism to specify the hardware architecture on which a package was designed to properly function. Through the use of this field, accidental installation of binaries which are not executable on a given platform may be prevented.

Software Identifiers

Software identifiers delineate the identity of the contents within a package. The SLPv5a specification defines these identifiers to be software name and software version.

The software name (delineated by the SoftwareName field) is most frequently an exact match of the name of the source archive used to create the package. Software names are decided by the original software author. Use of the original source archive name as the software name should only be ignored in the event a source archive is used to produce multiple packages (which each contain a portion of the proceeds from the build from sources); in this case, the package creator should select a name which is based on the original source name, but also references the specific contents held within the package.

The software version (delineated by the SoftwareVersion field) is most frequently an exact match of the version of the source archive used to create the package. The original software author typically provides a version indicator with each release. In extremely rare cases, it may be necessary to alter the author-supplied version indicator or synthesize a version indicator (such as in the case of a package built from an unofficial CVS snapshot). In the event that a piece of software is not provided with a version indicator, but is a standard release, a version indicator should not be synthesized.

Package Identifiers

Package identifiers provide a mechanism to permit the delineation of re-releases of a package from previous releases of that package. Package re-releases may be necessitated by improper build, mis-packaging or necessary improvement. The SLPv5a specification defines these identifiers to be package release index and package creation date.

The package release index (delineated by the PackageReleaseIndex field) is initialized to a value of one for the first release. Subsequent releases increment this index (i.e. when foobar-1.2-1 is found to have problems and is re-released, it shall be released as foobar-1.2-2). The index is independent for each set of system and software identifiers (the index is tracked individually); the index shall be reset to one on each version change (i.e. when version is changed from 1.2 to 1.3, release index is reset to one).

The package creation date (delineated by the PackageCreationDate field) is set to the GMT timestamp of the time when final package assembly took place. This timestamp should be semi-accurate. Day and month will follow the English language abbreviations regardless of locale.

5.2 Package Dependencies

Package dependencies provide a mechanism to define a list of supporting software needed to use another piece of software. Package dependencies are most frequently used to verify that a particular shared library, which is required to use a piece of software, has been installed. There are two basic components to the SLP v5a package dependency scheme: provision of dependencies and dependency requirements.

Dependencies Provided (Satisfied)

Each package provides itself as a list-able dependency, based on software name (SoftwareName), software version (SoftwareVersion) and release (PackageReleaseIndex).

Dependencies Required

Required (and optional) dependencies are listed in the DependsRequired field of the SLP v5a header. This field will contain a semi-colon delimited list of dependencies, based on the dependencies provided by the needed package. If a package has no dependency requirements, the DependsRequired field will be left empty.

The following format will be used for specifying dependencies:

SoftwareName(flags)[;SoftwareName(flags)[...]]
 

For example, full dependency on two packages (without need for additional version and revision specification), foobar and chicken, would be represented as:

foobar; chicken
 

Special flags will be used to represent the need for a particular version of a package, a particular release of a package, or to specify that a dependency is optional. Package versions and releases must be specified using one of three operators: == (equal to), >= (greater than or equal to), or <= (less than or equal to). Package release requirements must be accompanied by a package version requirement; only the leading (listed) version requirement will be used in conjunction with the release requirement. For example, if a dependency is listed for foobar, versions 1.2 and above, with release index greater than or equal to 2, version 1.2, release 2, or version 1.3 (any release) would satisfy this requirement.

When using multiple flags together, each flag and its arguments will be surrounded by parenthesis. Each flag has been assigned an activating character: 'V' for software version, 'R' for package revision index, and 'O' for optional. Any combination and order of flags is acceptable. Multiple version or revision flags are also acceptable (thus permitting you to specify a range of acceptable versions, through the use of two version flags, one providing the maximal version, the other providing the minimal version.

The following are sample uses of flag combinations.

The package foobar is required:

foobar
 

The package foobar is optionally required:

foobar(O)
 

Version 1.2 or greater of the package foobar is required:

foobar(V:>=1.2)
 

Version 1.2 or greater of package foobar is required; of version 1.2 of package foobar, only revision 2 or greater of this package satisfies this dependency requirement:

foobar((V:>=1.2)(R:>=2))
 

Version 1.2 or greater of package foobar is optionally required:

foobar((V:>=1.2)(O))
 

Version 1.2 or greater of package foobar is optionally required; of version 1.2 of package foobar, only revision 2 or greater of this package satisfies this dependency requirement:

foobar((V:>=1.2)(R:>=2)(O))
 

Version 1.2 or greater of package foobar is required; version 1.6 or less of package foobar is required; this dependency requirement specifies the range of acceptable versions of package foobar to be (inclusive) between 1.2 and 1.6:

foobar((V:>=1.2)(V:<=1.6))
 

Version 1.2 or greater of package foobar is optionally required. Of version 1.2 of package foobar, only revision 2 or greater of this package satisfies the dependency requirement. Version 1.6 or lower of package foobar is optionally required. Of version 1.6 of package foobar, only revision 3 or lower of this package satisfy the dependency requirement. This (complex) optional dependency specifies packages (inclusive) between foobar-1.2-2 and foobar-1.6-3 are acceptable.

foobar((V:>=1.2)(R:>=2)(V:<=1.6)(R:<=3)(O))
 

Version 2.1.3 or greater of glibc is required; version 5.005_05 of perl is optionally required:

glibc(V:>=2.1.3);perl((V:>=5.005_05)(O))
 

5.3 Security Enhancements

Point of origin

This section of the document is pending merge from internal sources.

Cryptographic Signatures

This section of the document is pending merge from internal sources.

Secure File Hashes

This section of the document is pending merge from internal sources.


Next Previous Contents