pkgwrite - Make RedHat and Debian packages from the same source.
pkgwrite (--tarball=TARBALL | --srcdir=SRCDIR) \
[--pkgwriteinfo-file=pkgwriteinfo] \
--arch=ARCH \
--format={redhat,debian}
[options]
pkgwrite --query-list=LISTNAME
pkgwrite takes a standard automake package, either from a source directory
or from a distributed tarball, and a pkgwrite input file
and makes either RedHat or Debian packages.
The actual package source code must be specified either by directory (using --srcdir) or from a tarball created with `make dist' (using --tarball).
Additional packaging information is taken from pkgwriteinfo. If --pkgwriteinfo-file is omitted, pkgwriteinfo from the source directory or tarball is taken instead. (after configure is run, so you might generally use a pkgwriteinfo.in).
There are a few command-line parameters which affect the package-making:
/tmp/mkpkg-###-$USER). Useful for debugging.
stable or unstable is recommended.
{MAIN} build.
{MAIN}
because the package is an all-or-nothing proposition.
Some packages contain many parts, not all applicable to all users. These packages should be broken in to different targets.
For example, a client/server based application might be
conveniently packaged foo-server, foo-client-curses, foo-client-gtk.
That way, users without X can use the curses version without
installing gtk+, often the clients and servers are run exclusively on
different machines, so installing both is a waste of disk space.
The resulting system-dependent binary's name is just
the main Package: name if the Target: is {MAIN};
otherwise it will be the Package and Target separated by
a hyphen (-).
We recommend that you maintain a changelog in debian format, here is an example:
gdam (0.934-1) unstable; urgency=low
* many bug fixes * split into many packages
-- David Benson <daveb@ffem.org> Wed, 17 Jan 2000 13:09:36 -0800
(No spaces for each version banner; 2 spaces on each bullet; 1 space before the packager byline.)
If you don't maintain a changelog, we will generate a changelog with just this version of the package in it.
You should specify the changelog using the Changelog: directive.
Here are a few examples of common types of packages.
The pkgwrite distribution includes these packages
inside the examples/tiny directory.
The most common type of package has one set of files it installs or uninstalls: there are no packaged bits or pieces. (A Target in pkgwrite terminology is the installed set of files.)
Here is the pkgwrite file from the single-target example included with the pkgwrite distribution:
Package: aa Section: text Group: Applications/Text Priority: low Home-Page: NONE Source-Url: NONE Author: David Benson <daveb@ffem.org> Version: 0.0.8 Release: 1 Synopsis: test package aa Packager: daveb Packager-Email: daveb@ffem.org License: NONE Description: test package (aa).
Build: {MAIN}
Target: {MAIN}
Files: /usr/bin/dummy-*
Synopsis: test a (single-target package)
This package's name is aa; this file will produce a binary RPM
named aa-0.0-1.$ARCH.rpm.
a, but debian packages must be at least two
letters.
$ARCH is the target architecture, for example
i386, alpha, or powerpc.
The Target {MAIN} is special, it
means ``don't use any suffix'' -- the package's
name is to be aa. For any other Target line,
if STRING was specified, the resulting
RPM or deb would have the name aa-STRING.
Each wildcard from Files lines describe a file or files to move
into that target.
Unlisted files will not wind up in any binary package.
A multi-target, single-build package is a package that need only be compiled once, but which must be separated into several system packages, because the targets appeal to different users or have different dependencies.
Here is the pkgwriteinfo file from the example multi-target single-build package:
Package: bb Section: text Group: Applications/Text Priority: low Home-Page: NONE Source-Url: NONE Author: David Benson <daveb@ffem.org> Version: 0.0 Release: 1 Synopsis: test package bb Packager: daveb Packager-Email: daveb@ffem.org License: NONE Description: test package (bb).
Build: {MAIN}
Target: a Files: /usr/bin/bb-a Synopsis: part a of package bb Description: whatever (bb-a)
Target: b Files: /usr/bin/bb-b Synopsis: part b of package bb Description: whatever (bb-b)
In this package, only a single default Build: is required.
Some packages may require the Configure-Flags or
Configure-Envars fields in order to compile correctly.
By default, all the targets use the {MAIN} Build.
Then each package contains a default file list, a description and a synopsis.
The most complex type of package must be built multiple times,
with different configure or make flags. Each target must then
refer to the build from which it was produced,
using the Which-Build field (the default is {MAIN}).
Here is the example of such a package from the pkgwrite
distribution:
Package: cc Section: text Group: Applications/Text Priority: low Home-Page: NONE Source-Url: NONE Author: David Benson <daveb@ffem.org> Version: 0.0 Release: 1 Synopsis: test package cc Packager: daveb Packager-Email: daveb@ffem.org License: NONE Description: test package (cc).
Build: nond Configure-Flags: --program-suffix=-nondebug
Build: d Configure-Flags: --program-suffix=-debug
Target: nondebug Which-Build: nond Files: /usr/bin/test-nondebug Synopsis: nondebug package cc Description: whatever (cc-nondebug)
Target: debug Which-Build: d Files: /usr/bin/test-debug Synopsis: debug package cc Description: whatever (cc-debug)
Each Build section corresponds to a complete configure, build, install phase.
In this package, the nond build just wants configure to be run
configure --program-suffix=-nondebug ...
whereas for the d build,
configure --program-suffix=-debug ...
(Note that the ... will be somewhat different from distribution to
distribution)
Also, it is often convenient to use the same names for the builds and
the targets. We would rename nond as nondebug and d as debug
if this were a real package -- we did this to discuss it more
conveniently.
It is perfectly possible to have more than one Target pointing to the same Build, just as multi-target single-build packages do. But the opposite is not allowed: a Target must specify exactly one Build.
Many lists and values are hardcoded into pkgwrite. You may query these lists through the --query-list flag. Here are the lists you may obtain in this manner:
For example to get a list of allowed values for the Section:
field, use pkgwrite --query-list=deb-sections.
This (long) section describes the file
that describes the targets to build from a tarball.
This description file is called a pkgwriteinfo file.
The pkgwriteinfo file consists of one package description part,
then a number of Build sections,
then a number of Target sections.
The package file should begin with a section that describes the overall source code of the package:
Package: gdam Section: sound Group: Multimedia/Sound Priority: optional Home-Page: http://ffem.org/gdam Source-Url: http://ffem.org/gdam/downloads/gdam-0.0.930.tar.gz Version: 0.0.930 Release: 1 Author: David Benson <daveb@ffem.org>
Here is a description of each allowed field:
pkgwrite)
is the same as the upstream maintainer of a package.
Right now, this only affects the filename used for the changelog,
it will either be changelog.gz if they are the same person,
or changelog.Debian.gz if they are not.
For each output binary package there must be a ``target'' section:
Target: xmms-plugins Depends: gdam-clients-gtk, gdam-server, xmms Synopsis: GDAM XMMS plugin support Description: use XMMS visualization plugins with GDAM. Files: /usr/bin/gdamxmmsvishelper
gdam-xmms-plugins.
yes if this package will be installable on
any architecture (it contains no system-specific or compiled code).
Set this to no for packages containing compiled,
architecture-specific binaries.
Depends: lines by default;
this is just in case we cannot guess correctly.)
Conflicts: by default.
pkgwrite.1.
It will automatically be installed into the correct
section directory based on its extension.
It will be always be copied into the distribution's documentation area, and it will be gzip'd if that is needed. Also, whole directories will be recursively copied, if the entry ends with a /, for example,
Doc: /usr/share/doc/gdam/example-configs/
These must be files directly from the distributed tarball. They will be always be copied into the distribution's documentation area and will be gzip'd if that is needed. Whole directories will be recursively copied, if the entry ends with a /.
{MAIN}).
{MAIN}.
configure script.
make program during both
the build and the install phase.
make program during just
the build phase.
make program during just
the install phase.
make target that is necessary to build the package,
that is not run by the default target. This must not
require root priviledges. (You may specify
any number of Extra-Build-Targets: lines.)
make target that is necessary to install the package,
that is not run by the default target. On Debian systems, these commands
may require root or fakeroot. (You may specify
any number of Extra-Install-Targets: lines.)
If you have problems, here are some hints:
--no-cleanup flag or equivalently have the DO_CLEANUP
environment variable set to 0. (You can find the
directory where work was done by running: ls -ltr /tmp/mkpkg-*)
Otherwise, redirect the output to a log file and read the whole thing.
Some packaging systems output a log of messages
even after a fatal error.
Then, try and cut out pieces of the pkgwriteinfo
file until you locate the problem.
Report a bug if the problem is clear.
Here are some trivial mistakes made often:
pkgwriteinfo is generated by configure from pkgwriteinfo.in.
It is easy to forget to rerun configure and very slow.
I don't know of any easy solution to forgetting
at the moment, but you may just run config.status
instead, in order save time.
Of course, you can and should work however you want, but for your information, I will write the testing process I use for releasing packages.
I always make automake packages that use
pkgwriteinfo inside the tarball.
It is important to note that my packages always
support make rpm and make deb using pkgwrite,
and that these targets only make dist if the tarball
isn't present!
bootstrap
(as recommended by the automake authors), but many packages
use ./autogen.sh, which traditionally also runs ./configure.
If you used bootstrap, you will need to run ./configure.
Then make the tarball using make distcheck.
./configure, then
make rpm and make deb, respectively.
Copy all the returned packages, the dist tarball,
into a directory which you will upload.
Test install those packages on machines.
I also inspect them with the following commands:
System| RedHat Debian
Action |
--------------+------------------------------------------------
List of files | rpm -qpl *.rpm dpkg-deb -c *.deb
General data | rpm -qpi *.rpm dpkg-deb -e *.deb
TODO
Written by Dave Benson <daveb@ffem.org>.