File: 01-preface.txt

package info (click to toggle)
debmake-doc 1.22-1
  • links: PTS, VCS
  • area: main
  • in suites: sid, trixie
  • size: 12,952 kB
  • sloc: makefile: 916; sh: 692; python: 202; ansic: 114; sed: 16
file content (38 lines) | stat: -rw-r--r-- 3,905 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// vim:set filetype=asciidoc:
If you are a somewhat experienced Debian user footnote:[You need to know a little about Unix programming, but you don't need to be an expert. You can learn about basic Debian system handling from the "`https://www.debian.org/doc/user-manuals#quick-reference[Debian Reference]`". It also contains pointers for learning about Unix programming.], you may have encountered the following situations:

* You wish to install a certain software package not yet found in the Debian archive.
* You wish to update a Debian package with the newer upstream release.
* You wish to fix bugs of a Debian package with some patches.

If you want to create a Debian package to fulfill these needs and share your work with the community, you are the target audience of this guide as a prospective Debian maintainer. footnote:[If you're not interested in sharing the Debian package, you can address your local needs by compiling and installing the fixed upstream source package into */usr/local/*.]  Welcome to the Debian community.

Debian has many social and technical rules and conventions to follow, as it is a large volunteer organization with a rich history. Debian has also developed an extensive array of packaging and archive maintenance tools to build consistent sets of binary packages that address many technical objectives:

* packages have clearly specified package dependencies and patches and build correctly from scratch in a clean build environment ("`<<control>>`", "`<<patches>>`", "`<<sbuild-setup>>`")
* packages build across many architectures ("`<<rules-variables>>`")
* builds are reproducible ("`<<reproducible>>`")
* multiarch is supported ("`<<multiarch>>`")
* bootstrapping new architectures is possible ("`<<bootstrap>>`")
* builds use specific compiler flags to harden security ("`<<harden>>`")
* packages are split optimally into multiple binary packages ("`<<split>>`")
* library names and contents are managed to ensure smooth transitions on upgrades ("`<<lib-trans>>`")
* installations use interactive prompts correctly (if at all) ("`<<debconf>>`")
* continuous integration is used to ensure quality ("`<<ci>>`")
* ...

These factors can be overwhelming for many new prospective Debian maintainers. This guide aims to provide entry points to help them get started. It covers the following:

* What you should know before getting involved with Debian as a prospective maintainer.
* What it looks like to make a simple Debian package.
* What kind of rules exist for making the Debian package.
* Tips for making the Debian package with minimal effort.
* Examples of making Debian packages in typical scenarios.

The author recognized the limitations of updating the original "`New Maintainers' Guide`" with the *dh-make* package and decided to create an alternative tool with accompanying documentation to address modern requirements such as multi-arch. This resulted in the *debmake* package, initially released as version 4.0 in 2013. The current *debmake* version is @@@debmakeversion@@@. It comes with this updated "`https://www.debian.org/doc/manuals/debmake-doc/[Guide for Debian Maintainers]`" in the *debmake-doc* package (version: @@@debversion@@@). (In 2016, *dh-make* was ported from Perl to Python with updated features.)

Many chores and tips have been integrated into the *debmake* command allowing this guide to be terse.  This guide also offers many packaging examples for you to get started.

CAUTION: It takes many hours to properly create and maintain Debian packages. The Debian maintainer must be *both technically competent and diligent* to take up this challenge.

Some important topics are explained in detail. While some may seem irrelevant to you, please be patient. Certain corner cases are omitted, and some topics are only covered through external references. These are intentional choices to keep this guide simple and maintainable.