| 1 |
The idea of polypkg is to supply a common packaging script that can
|
| 2 |
be converted into packaging commands on various different platforms.
|
| 3 |
|
| 4 |
The style is to provide reasonable defaults for everything, but allow
|
| 5 |
platform-specific overrides/explicits at every place.
|
| 6 |
|
| 7 |
(Use portable shell <http://sourceware.org/autobook/autobook/autobook_220.html>)
|
| 8 |
|
| 9 |
Platforms
|
| 10 |
---------
|
| 11 |
The package systems we're interested in are
|
| 12 |
|
| 13 |
rpm (Red Hat Linux)
|
| 14 |
bff (AIX)
|
| 15 |
pkg (Solaris)
|
| 16 |
sw (HP-UX)
|
| 17 |
|
| 18 |
Package components
|
| 19 |
------------------
|
| 20 |
From what I can see, the common components of packages on each platform are:
|
| 21 |
|
| 22 |
- run ('usr', runtime binaries; bulk of package) [mandatory]
|
| 23 |
+ ('root', configuration files, system modules, init linkage)
|
| 24 |
- doc (man pages, readmes)
|
| 25 |
- dev (developer libraries, header files)
|
| 26 |
|
| 27 |
Dependency tree:
|
| 28 |
run
|
| 29 |
+cfg
|
| 30 |
+doc
|
| 31 |
+dev
|
| 32 |
|
| 33 |
(Source is a single multi-platform tar.gz; use autoconf & include pp.)
|
| 34 |
|
| 35 |
Of course the components need not be separated like this.
|
| 36 |
On RPM these map into %{name}, %{name}-doc, %{name}-dev, etc
|
| 37 |
On AIX these are filesets .rte, .adt etc, and split root/usr
|
| 38 |
|
| 39 |
Server packages
|
| 40 |
---------------
|
| 41 |
Server packages are special and all too common. Platforms usually have
|
| 42 |
a mechanism to manage services started at boot, usually modelled on
|
| 43 |
SysV's init scripts. I want polypkg to have template scripts for
|
| 44 |
each platform that just work. We'll make the assumption that services
|
| 45 |
are simple non-forking processes, started with arguments, that don't write
|
| 46 |
a PID file and are controlled with signals.
|
| 47 |
|
| 48 |
A special section "%service $name" will add start/stop init scripts for the
|
| 49 |
service. the section contains these assignents
|
| 50 |
|
| 51 |
svc_cmd: single program followed by args
|
| 52 |
svc_daemon: 'yes' if the cmd background; 'no' if it doesn't [dflt]
|
| 53 |
svc_pid: pid file written, or empty if none [dflt]
|
| 54 |
svc_stopsig: signal used to stop the server ([dlt] TERM)
|
| 55 |
svc_user: user to run service as ([dflt] root)
|
| 56 |
|
| 57 |
if $svc_pid is empty, it gets set internally to a platform-agreeable path,
|
| 58 |
and code will be added to capture the PID of the command at startup.
|
| 59 |
$svc_daemon must be 'no' in this case.
|
| 60 |
|
| 61 |
if $svc_user is not root, then the user is created at post-install
|
| 62 |
|
| 63 |
SuSE/Red Hat is a good example where polypkg can detect at runtime
|
| 64 |
what kind of init script to install. (LSB or insserv)
|
| 65 |
|
| 66 |
Package descriptions
|
| 67 |
--------------------
|
| 68 |
Most packages have some human-readable descriptions. We'll try to form
|
| 69 |
the union of information that each native packaging system has,
|
| 70 |
and default as much as possible.
|
| 71 |
|
| 72 |
short name $name
|
| 73 |
brief summary $brief
|
| 74 |
long description $description
|
| 75 |
vendor name $vendor
|
| 76 |
packager name $packager
|
| 77 |
maintainer email $maintainer
|
| 78 |
home page url $url
|
| 79 |
category
|
| 80 |
|
| 81 |
Version numbering
|
| 82 |
-----------------
|
| 83 |
Version numbering is usually fairly flexible, but the lowest common
|
| 84 |
denominator is four integers, period-delimited, <major.minor.micro.build>.
|
| 85 |
|
| 86 |
For RPM, the 'release' field should always be '1'.
|
| 87 |
|
| 88 |
|
| 89 |
Package file lists
|
| 90 |
------------------
|
| 91 |
Packages generally consist of a file tree that is overlaid onto
|
| 92 |
the target host's root file system.
|
| 93 |
|
| 94 |
pp shall NOT support relocatable installs
|
| 95 |
|
| 96 |
All files are assumed to be installed already relative to $DESTDIR.
|
| 97 |
|
| 98 |
Mostly, what's important in a file list is
|
| 99 |
- the files (of course)
|
| 100 |
- directories to create if they're not there already (shared dirs!)
|
| 101 |
- permissions and ownership
|
| 102 |
- which files are 'volatile' (expected to change)
|
| 103 |
|
| 104 |
Wildcards can be used in the file list. This lets the packager tool
|
| 105 |
determine the files for you at packaging time, but leads to the risk
|
| 106 |
of adding files you don't want packaged.
|
| 107 |
|
| 108 |
Package post-install and pre-remove scripts
|
| 109 |
-------------------------------------------
|
| 110 |
|
| 111 |
These are scripts run just after install, or just before uninstall
|
| 112 |
|
| 113 |
|
| 114 |
Style
|
| 115 |
-----
|
| 116 |
I like lines that start with a special, unusual character. Let's use '%'.
|
| 117 |
Single line comments starting with '#'.
|
| 118 |
Something that is easy to be processed by shell scripts. Especially
|
| 119 |
with the shell's 'eval' operator.
|
| 120 |
|
| 121 |
Allow shell vars to be set for the %set section. These override settings
|
| 122 |
later.
|
| 123 |
|
| 124 |
Lines that apply to one packaging system only should be prefixed with
|
| 125 |
[foo]. Or [!foo], or [foo,bar] or [!foo,bar]
|
| 126 |
|
| 127 |
%post[-install] and %pre[-remove] sections can be followed by
|
| 128 |
a list of packaging systems. They get merged together in the order specified.
|
| 129 |
Actually, Allow all sections get merged together like that.
|
| 130 |
|
| 131 |
Source tarballs
|
| 132 |
---------------
|
| 133 |
I think source tarballs will have this kind of directory structure:
|
| 134 |
|
| 135 |
<name>-<version>/
|
| 136 |
+-- dist/ - distribution sources, patches, polypkg script
|
| 137 |
+-- Makefile - toplevel makefile (targets: build, package)
|
| 138 |
+-- plat.<plat>.mk - platform-specific makefile fragments
|
| 139 |
+-- <name>.pp - packaging script
|
| 140 |
+-- NEWS - summary of changes updated for major releases
|
| 141 |
+-- ChangeLog - detailed log messages from source repository
|
| 142 |
+-- pp - distributable polypkg script
|
| 143 |
|
Parent Directory
| 
Revision Log