polypkg
Status:	beta

PolyPkg - cross platform packaging tool

Cross-platform packaging tools are not new. At Resource Central, I found that most of my time was being spent re-inventing the wheel, manually creating packages for our Quest Authentication Services-enabled software, and maintaining them. PolyPkg (pp) attempts to automate these efforts.

Design goals
Synopsis
Examples
Architecture
Availability
See also

Design goals

pp is a shell script with the following design goals/wish list

easily redistributable with source packages (cf. configure, libtool)
portable across platforms of interest (Linux, AIX, HPUX, Solaris)
uses native platform package management tools (rpm, swinstall, installp, pkgadd)
generates init scripts for services
understands a lowest common denominator subset of 'components'. Components are independent but related packages, and currently include runtime documentation, developer libraries and debugging information
can generates the debug component automatically
the input text is conceptually an extension of Bourne Shell (i.e. no new language to learn, yet permits fine-control, uh.. hacks)
all symbols start with pp_ to avoid user script conflict
can automatically copy packages into a snapshot distribution area with a sane layout
parameter substitution in post-install/service script fragments

Synopsis

usage: pp [options] [input.pp]
    -d --debug                  -- write copious info to stderr
       --destdir=path           -- defaults to $DESTDIR
    -? --help                   -- display this information
    -i --install                -- install after packaging
    -l --list                   -- write package filenames to stdout
       --no-clean               -- don't remove temporary files
       --no-package             -- do everything but create packages
       --only-front             -- only perform front-end actions
    -p --platform=platform      -- defaults to local platform
       --wrkdir=path            -- defaults to subdirectory of  or /tmp
    -v --verbose                -- write info to stderr
       --version                -- display version and quit

You can also look at the crude documentation.

Examples

DNSUpdate
Quest Sudo
Sudo (more complex)

Architecture

As a shell script, pp has a simple design:

             ------------PolyPkg-----------
spec file -> front-end -> model -> back-end -> package
             ------------------------------

Front end: This stage parses the spec file; removes comments, and performs section handling. It either calls into the model on each line of input, or stores section bodies into files to pass to the model later.
Model: The model stage is just an internal representation of the package: the number of components defined, names of declared services, and also provides a generic view of the file set. The result of this stage is a directory full of well-known file names containing pre-examined/processed filenames, script fragments etc.
Back end: This is the platform-specific code which takes the collection of script fragment files, fileset lists and generates the output package file(s).

Availability

You can browse the project source or check out a copy for yourself from the GitHub polypkg repository.

Resource Central