| Kapitel 16. debmake options | ||
|---|---|---|
 |
||
| Kapitel 16. debmake options | ||
|---|---|---|
| |
||
Inhaltsverzeichnis
Here are some additional explanations for debmake options.
The debmake command offers a shortcut option.
Das Beispiel in obigem „Kapitel 5, Simple packaging“ kann so einfach wie folgt sein.
[base_dir] $ debmake package-1.0.tar.xz -i debuild
![[Tipp]](images/tip.png) | Tipp |
|---|---|
|
A URL such as „https://www.example.org/DL/package-1.0.tar.xz“ for a tarball, „https://github.com/username/package.git“ for a git repository, or „/path/to/source_dir“ for a local source tree may be used as an argument. |
The debmake command with the -b option provides an intuitive and flexible method to create the initial template debian/control file. This file defines the split of the Debian binary packages with the following stanzas:
The debmake command also sets an appropriate set of substvars (substitution variables) used in each pertinent dependency stanza.
Let’s quote the pertinent part from the debmake manpage here.
set the binary package specs by a comma separated list of binarypackage:type pairs. Here, binarypackage is the binary package name, and the optional type is chosen from the following type values:
The pair values in the parentheses, such as (any, foreign), are the Architecture and Multi-Arch stanza values set in the debian/control file. In many cases, the debmake command makes good guesses for type from binarypackage. If type is not obvious, type is set to bin.
Here are examples for typical binary package split scenarios where the upstream Debian source package name is foo:
Generating an executable binary package foo:
Generating an executable (python3) binary package python3-foo:
Generating a data package foo:
Generating a executable binary package foo and a documentation one foo-doc:
Generating a executable binary package foo, a library package libfoo1, and a library development package libfoo-dev:
If the source tree contents do not match settings for type, the debmake command warns you.
This test building scheme is suitable for git repositories organized as described in gbp-buildpackage(7), which uses the master, upstream, and pristine-tar branches.
The upstream snapshot from the upstream source tree in the upstream VCS can be made as:
[~] $ cd /path/to/upstream-vcs [upstream-vcs] $ debmake -p package -i debuild
If the upstream VCS is hosted in the package/ directory instead of the upstream-vcs/ directory, the „-p package“ can be skipped.
If the upstream source tree in the VCS contains the debian/* files, the debmake command with the -i option automates the making of a non-native Debian package from the VCS snapshot while using these debian/* files.
[upstream-vcs] $ dch ... update debian/changelog [upstream-vcs] $ git add -A .; git commit -m "vcs with debian/*" [upstream-vcs] $ debmake -p package -i debuild
This non-native Debian binary package building scheme without the real upstream tarball is considered a quasi-native Debian package. See „Abschnitt 11.12, „Quasi-native Debian packaging““ for more details.
The debmake command invoked with the -B option can generate template files with .ex suffix. This is handy if you want to see auto-generated template files to the existing ones.
The amount of template files generated by the debmake command depends on the -x[01234] option.
![[Anmerkung]](images/note.png) | Anmerkung |
|---|---|
|
None of the existing configuration files are modified by the debmake command. |
| |
||
| Kapitel 15. debmake(1)-Handbuchseite |
|