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.
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
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.
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.
- 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).
You can browse the project source or check out a copy for yourself from the GitHub polypkg repository.
Other cross-platform packaging tools with similar goals to pp include:
— David Leonard