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:
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:
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 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.
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 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:
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.
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
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 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: