Creating a quality Debian package is not always a simple task, and becoming a package maintainer takes some learning, both with theory and practice in technical and legal matters. It is not a simple matter of building and installing software; rather, the bulk of the complexity comes from understanding the problems and conflicts, and more generally the interactions, with the myriad of other packages available.
A Debian package must comply with the precise rules compiled in the Debian policy, and each package maintainer must know them. There is no requirement to know them by heart, but rather to know they exist and to refer to them whenever a choice presents a non-trivial alternative. Every Debian maintainer has made mistakes by not knowing about a rule, but this is not a huge problem as long as the error gets fixed when a user reports it as a bug report (which tends to happen fairly soon thanks to advanced users). The
Standards-Version field in
debian/control specifies the version of the Debian policy with which a package complies. Maintainers should comply to the latest version of the Debian policy.
パッケージメンテナの作業を手助けする数多くのツールが存在します。この節では、それらのツールを簡単に説明します (詳細は説明しません)。なぜなら、これらのツールには自分自身を解説する総合的な文書が用意されているからです。
devscripts パッケージには、Debian 開発者が行う作業の大部分に対する手助けを行う数多くのプログラムが含まれます。
debuild を使うことで、(dpkg-buildpackage から) パッケージを生成したり、Debian ポリシーへの遵守を確認するために後から lintian を実行することが可能です。
debclean を使うことで、バイナリパッケージを生成した後にソースパッケージの後片付けをすることが可能です。
dch を使うことで、素早く簡単にソースパッケージ中の debian/changelog ファイルを編集することが可能です。
uscan を使うことで、上流開発者がソフトウェアの新しいバージョンをリリースしたか否かを確認することが可能です。確認を行うにはリリースの場所が書かれた debian/watch ファイルが必要です。
debi を使うことで、Debian パッケージを生成した直後に (dpkg -i を使って) そのパッケージをインストールすることが可能になります。パッケージの完全な名前やパスを指定する必要はありません。
debc を使うことで、Debian パッケージを生成した直後に (dpkg -c を使って) そのパッケージの内容を調査することが可能です。パッケージの完全な名前やパスを指定する必要はありません。
bts controls the bug tracking system from the command line; this program automatically generates the appropriate emails.
debrelease を使うことで、Debian パッケージを生成した直後にそのパッケージをリモートサーバにアップロードすることが可能です。関連する .changes ファイルの完全な名前やパスを指定する必要はありません。
debsign を使うことで、*.dsc と *.changes ファイルに署名することが可能です。
uupdate を使うことで、新しい上流開発版がリリースされた場合にパッケージの新しい修正版の作成を自動化することが可能です。
All of the mentioned commands are documented in their respective manual pages. They can further be configured per user in one file: ~/.devscripts.
15.4.1.3.2. debhelper と dh-make
Debhelper is a set of scripts easing the creation of policy-compliant packages; these scripts are invoked from debian/rules. Debhelper has been widely adopted within Debian, as evidenced by the fact that it is used by the majority of official Debian packages. All the commands it contains have a dh_ prefix. Each of them is documented in a manual page. The different compatibility levels and common options are described in debhelper(7).
dh_make スクリプト (dh-make パッケージに含まれます) はソフトウェアのソースが含まれるディレクトリ内に Debian パッケージを生成するために必要なファイルを作成します。dh_make という名前から推測される通り、生成されたファイルはデフォルトで debhelper を使います。
This tool is one of the most important: it is the Debian package checker. It is based on a large array of tests created from the Debian policy, and detects quickly and automatically many errors that can then be fixed before packages are released.
lintian の情報は参考程度にしかならず、間違いを犯すこともあります (たとえば、Debian ポリシーは常に変わるものなので、しばしば lintian は時代遅れになることがあります)。また、lintian は徹底的な調査を行いません。すなわち、lintian がエラーを出さないことを理由に対象のパッケージが完全であると結論付けてはいけません。lintian を使ってわかることはせいぜい最も一般的な間違いを犯していないことだけです。
piuparts もまた重要なツールの 1 つです。すなわち、piuparts は (隔離環境の中で) パッケージのインストール、アップグレード、削除、完全削除の作業を自動化し、これらの作業中にエラーが起きないことを確認します。piuparts は不足している依存関係を検出したり、パッケージが完全削除された後にファイルが誤って残されたことを検出したりする際にも役立ちます。
autopkgtest runs tests on binary packages, using the tests supplied in the source package in debian/tests/. Several commands allow the easy creation of chrooted or virtual test environments.
reprotest builds the same source code twice in different environments, and then checks the binaries produced by each build for differences. If any are found, then diffoscope (if unavailable, diff) is used to display them in detail for later analysis.
15.4.1.3.7. dupload と dput
The dupload and dput commands allow uploading a Debian package to a (possibly remote) server. This allows developers to publish their package on the main Debian server (ftp-master.debian.org) so that it can be integrated to the archive and distributed by mirrors. These commands take a .changes file as a parameter, and deduce the other relevant files from its contents.
15.4.1.3.8. git-buildpackage and dgit
The project has been using various version control systems over the years to store packaging efforts or package source code, or allow collaborative package maintenance. In an effort to unify the systems and efforts, it was ultimately decided in 2017 to move (almost) all package sources into
Git (
「CULTURE Git」) onto a Gitlab instance called
salsa.debian.org.
To make packaging using Git easier for Debian developers, tools have been developed. These allow not only to store the packaging files in Git, but also to use the Git repositories (and their history) of software projects, put patches applied to package sources into Git history, maintain software versions per distribution, etc.
One of the most famous packages is git-buildpackage. An alternative is dgit. Of course it is still possible to use neither of those.
Below is an example for a ~/.gbp.conf configuration file
[DEFAULT]
builder = sbuild -d bullseye --build-dep-resolver=aptitude -s --source-only-changes --build-failed-commands "%SBUILD_SHELL"
pristine-tar = true
[buildpackage]
sign-tags = true
keyid = XXXX
postbuild = autopkgtest --user debci --apt-upgrade -s "$GBP_CHANGES_FILE" -- lxc --sudo autopkgtest-bullseye-amd64
export-dir = /tmp/build-area/
notify = off
[import-orig]
filter-pristine-tar = true
sign-tags = true
[pq]
drop = true
Building the package is then as easy as running gbp buildpackage in the Git tree. It will start a package build in a Debian Bullseye chroot using sbuild. When the build succeeds, the created files are checked running the autopkgtest-testsuite (if defined). All the various options are explained in gbp.conf(5) and /etc/git-buildpackage/gbp.conf.
All the tools mentioned so far have been included in the continuous integration (CI) process in the
salsa.debian.org instance as well:
