PW32: Packaging conventions


PW32 packaging conventions are based on ones of DJGPP. I consider as the greate benefit an possibility to install package by simply unpacking it, while still leave room for automated package maintanance. However, for improving the latter, obviously, some extentions to simple DJGPP scheme should be made. However, they are dictated, and constrained by following design goals:

  1. Package phisically is archive of common type, i.e. zip or tar.gz. Zip is strongly preferred.
  2. Using zip should not lead to inability to transfer such important POSIX notions as file permissions and ownership. So, some explicit way to represent them should exist. This also useful per se, so no access to original package needed for such operation as testing integrity of installation.
  3. Mere unpacking package archive in the appopriate place is legal way of installing it. It may leave some artefacts, for example orphaned files from previous version, which won't happen if proper package-manager-driven procedure were performed, but resulting state of entire installation should be correct.
  4. From the above stems that no special package databases can be maintained. Instead, all bookkeeping and setup information should be represented by per-package files, for what adequate conventions should be elaborated.

It should be noted that, as far as I know and per my opinion, no existing *nix-born packaging scheme satisfies conditions above. Or even is some do, it's not easy to get knowledge of this. Even highly-popular RPM is underdocumented, IMHO, while still being overcomplicated (but featureful, for sure; still, IMHO, many those features are not largely applicable to most common usage patterns).

Fortunately, there's an effort to create elaborated package manager for DJGPP - zippo project. While I consider trunk of ideas behind zippo to be very well worked out, some details can be generalized/developed further. Zippo supposed to be used with existing packages, while that's not true for PW32, so there's no need to drag old stuff along. Also, zippo seem not to address point (2) above. Also, package manager under development seems to bother maintaining some databases, while I consider that superfluous.

Summing up, zippo's DSM specification taken as the base for specifying package properties, with following most notable extensions to DJGPP/zippo packaging scheme:

Technical specifications

Package layout

Package is the set of files, distributed across directories. Each particular package represents layout of files and directories relative to installation $prefix. On the top level, only directories are permitted. These top-level directories are also not arbitrary, but should be of ones specified by [external] conventions.

Packages can be relocatable - those which can be installed under any $prefix and absolute - ones which supposed to be installed into prespecified location (e.g. due to compiled-in paths).

Package name

Package name should reflect name of the software contained in the package and should not depend on other properties of software - such as package type (but see Library packages conventions), version, etc. Package name is used as the basename for some of the package description files (see below). This allows for "automatical" updating of bookkeeping information with manual upgrade - description files of new version will simply overwrite those of older.

Package information directory

One of the mandatory top-level directory is directory 'manifest' which must contain package description files. Currently, there are two such file per package: extended manifest file and extended ver file.

Extended manifest file

Extended manifest file is contained in manifest subdirectory of every package and should be named as <package_name>.mft. File contains one line for each file (not a directory) of the package. Each line consist of several whitespace (sequence of one or more space and/or tab) separated fields. If filed contains whitespace characters it, must be quoted with double-quotes (though, having whitespaces in values whould be avoided). No field except first is mandatory. Field may be left unspecified by using '-' (hyphen) as its value. Trailing unspecified fields may be stripped. Manifest may have records with inconsistent number/spcificatedness of fields.

Meanings of the fields are:

  1. Relative (to top-level package directory) pathname of file.
  2. Size in bytes.
  3. Modification time in ISO format (YYYY-MM-DDThh:mm:ss, where 'T' is literal).
  4. POSIX permissions, as output by ls command.
  5. Owner of file.
  6. Group of file.

Extended ver file

Extended ver file is contained in manifest subdirectory of every package and should be named as <package_name>.ver. It specifies package properties and consists of two parts: legacy and dsm, separated by empty line. Legacy part consist of one (standard) or more lines representing name/short description of the package, and dsm part follows in syntax DSM specification. See DSM extensions for new directives and extended values for existing directives. It is recommended that legacy description match content of 'short-description' DSM directive, probably also specifying software version.

DSM extensions

Amended directives


Having dsm package with source is considered superfluous, so 'source' value is depricated. It is recommnded that packages were distributed as produced by 'make install' command. Such type is named 'standard'. If software package is big, its documentation may be packaged separately as documentation. Whenever some manual amendments was done to standard package described above (for example, was added important, per packager, documentation file which is not copied by make install), such package gets status 'extended'.

Outline above applies to end-user packages, for libraries, nicer destinction is recommended, see above. Values are binary, development, documentation, utilities.

Summary: dsm-type = binary | development | documentation | utilities | standard | extended

Added directives


This is generalization of simtelnet-path: source-repository specifies primary Internet repository containing package's sources, and source-repository-path gives pathname to source package within it (or any mirror of).

Library package conventions

Library packages are special because they do not contain closed, end user software, but rather auxilary components for other software. Hence, special packaging conventions for libraries may be useful. Before proceeding with them, let's gather facts about win32 libraries:

  1. There are static and dynamic libraries.
  2. Static libraries are exactly what they in the rest of the world: ar archive file with name having following patern: lib<library_name>.a.
  3. Dynamic library consist of two parts: so-called 'dll' and so-called 'import library'. Sic!, what corresponds to normal dynamic library (for example, ELF shared library) is spread across two files.
  4. Even though both files are required for full correspondence to the common dynamic library, each of the files have own purpose and own "schedule":
  5. Duality of win32 dynamic libraries can be seen in following way: implib describes interface of library, while dll is library implementation. It should be noted that dll is not a library in any way. Several characteristics show that it is executable, among them:

Paul Sokolovsky | use this form to submit bug