Here are the basics of package creation. They apply to a wide range of systems, from FreeBSD and OpenBSD to Arch Linux, Debian Linux, and Ubuntu Linux.
One makes a package by:
- Obtaining the source code tree, via git or subversion or some such, or by downloading and unpacking an archive file.
- Installing pre-requisite build packages, providing the tools that the software needs for compiling.
- Applying per-operating-system patches to that.
- Compiling the binaries and data files, however the particular software does that.
- Constructing a staging directory tree where the binaries and data files to package are laid out in that tree as they would be laid out under
/
after package installation.
- Using a package creation tool, in conjunction with a shipping manifest and some other metadata, to make the package.
Then one puts it into a package repository, either one that one runs onesself or one that is published by the operating system maintainers. There are a lot of logistical and political hoops to the latter process. In both, you need to deal with signing stuff.
The details vary from operating system to operating system, or rather from packaging system to packaging system. How package manifest files are structured varies, for example. And the Debian build-essential
metapackage is not a universal thing. But these are the general principles.
So all of those gibberish tools on the Ubuntu page are high-level wrappers for this, that do things like maintaining a source control repository of all of the extra stuff that you add on top of the original source code.
The Debian tooling is somewhat different. In fact, there are three different styles of Debian tooling, including "deb helper".
Also note that Debian instructions from various people around the WWW are often geared towards the idea that you are downloading an existing Debian source package and building it, rather than writing all of the ancillary Debian packaging stuff from scratch. Such a package has Debian packaging metadata, control files, and patches, already provided in the source tree. It is the original source plus the Debian packaging stuff.
Generally, a package constructs an appropriate staging tree itself if one gives it a target directory to "install" to instead of the /
directory. If you are packaging your own software, you have to provide a mechanism for correctly "installing" to a self-contained staging area. (I have "slashpackage" packages, with a package/stage
script that hoists everything out of command/
, manual/
, guide/
, library/
, et al. into a staging area suitable for /usr
.)
Finally: No you do not provide a van Smoorenburg rc
script for starting and stopping services. This hasn't been the native way on Ubuntu since 2006, nearly a decade and a half at this point. You provide systemd unit files. Even if you want to provide van Smoorenbrg rc
scripts for Debian people who aren't using systemd, you provide the new style van Smoorenburg rc
scripts, introduced in 2014, based on the example in the init-d-script
manual page, which are quite different in contents to what most (well out of date) WWW documentation will tell you.
Now you can go back to the details of debian/control
, debian/rules
, and suchlike on those (and other) WWW pages.
Further reading