| 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 VAS-enabled software, and maintaining them. PolyPkg (pp) attempts to automate these efforts.
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
quest-samba is an example of a complex package, yet its samba.pp file is relatively small.
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 either download the latest build of pp or check out the subversion repository, or browse the repository.
See also
Other cross-platform packaging tools with similar goals to pp include:
— David Leonard