Kapitel 6. Debmake-Optionen

Inhaltsverzeichnis

6.1. Abkürzungs-Optionen (-a, -i)
6.1.1. Python-Modul
6.2. Schnappschuss der Originalautoren (-d, -t)
6.3. debmake -cc
6.4. debmake -k
6.5. debmake -j
6.6. debmake -x
6.7. debmake -P
6.8. debmake -T

Es gibt einige bemerkenswerte Optionen für den Befehl debmake.

Der Befehl debmake bietet 2 Abkürzungsoptionen.

  • -a: öffnen des Tarballs der Originalautoren
  • -i: Ausführen der Skripte zum Bau des Binärpakets

Das obige Beispiel Kapitel 4, Einfaches Beispiel kann so einfach wie folgt sein.

 $ debmake -a package-1.0.tar.gz -i debuild
[Tipp] Tipp

Eine URL wie »https://www.example.org/DL/Paket-1.0.tar.gz« kann für die Option -a verwandt werden.

[Tipp] Tipp

Eine URL wie »https://arm.koji.fedoraproject.org/packages/ibus/1.5.7/3.fc21/src/ibus-1.5.7-3.fc21.src.rpm« kann auch für die Option -a verwandt werden.

The upstream snapshot from the upstream source tree in the VCS can be made with the -d option if the upstream package supports the “make dist” equivalence.

 $ cd /path/to/upstream-vcs
 $ debmake -d -i debuild

Alternatively, the same can be made with the -t option if the upstream tarball can be made with the tar command.

 $ cd /path/to/upstream-vcs
 $ debmake -p package -t -i debuild

Unless you provide the upstream version with the -u option or with the debian/changelog file, a snapshot upstream version is generated in the 0~%y%m%d%H%M format, e.g., 0~1403012359, from the UTC date and time.

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 either the -d option or the -t option combined with the -i option automates the making of a non-native Debian package from the VCS snapshot while using these debian/* files.

 $ cp -r /path/to/package-0~1403012359/debian/. /path/to/upstream-vcs/debian
 $ dch
   ... update debian/changelog
 $ git add -A .; git commit -m "vcs with debian/*"
 $ debmake -t -p package -i debuild

This non-native Debian binary package building scheme using the “debmake -t -i debuild” command may be considered as the quasi-native Debian package scheme since the packaging situation resembles the native Debian binary package building case using the debuild command without the upstream tarball.

Use of a non-native Debian package helps to ease communication with the downstream distros such as Ubuntu for bug fixes etc.

The debmake command with the -cc option can make a summary of the copyright and license for the entire source tree to standard output.

 $ tar -xvzf package-1.0.tar.gz
 $ cd package-1.0
 $ debmake -cc | less

With the -c option, this provides shorter report.

When updating a package for the new upstream release, the debmake command can verify the content of the existing debian/copyright file against the copyright and license situation of the entire updated source tree.

 $ cd package-vcs
 $ gbp import-orig --uscan --pristine-tar
 ... update source with the new upstream release
 $ debmake -k | less

The “debmake -k” command parses the debian/copyright file from the top to the bottom and compares the license of all the non-binary files in the current package with the license described in the last matching file pattern entry of the debian/copyright file.

When editing the auto-generated debian/copyright file, please make sure to keep the generic file patterns at the top of the list.

[Tipp] Tipp

For all new upstream releases, run the “debmake -k” command to ensure that the debian/copyright file is current.

The generation of a functioning multi-binary package always requires more manual work than that of a functioning single binary package. The test build of the source package is the essential part of it.

For example, let’s package the same package-1.0.tar.gz (see Kapitel 4, Einfaches Beispiel) into a multi binary package.

  • Invoke the debmake command with the -j option for the test building and the report generation.

     $ debmake -j -a package-1.0.tar.gz
  • Check the last lines of the package.build-dep.log file to judge build dependencies for Build-Depends. (You do not need to list packages used by debhelper, perl, or fakeroot explicitly in Build-Depends. This technique is useful for the generation of a single binary package, too.)
  • Check the contents of the package.install.log file to identify the install paths for files to decide how you split them into multiple packages.
  • Start packaging with the debmake command.

     $ rm -rf package-1.0
     $ tar -xvzf package-1.0.tar.gz
     $ cd package-1.0
     $ debmake -b"package1:type1, ..."
  • Update debian/control and debian/binarypackage.install files using the above information.
  • Update other debian/* files as needed.
  • Build the Debian package with the debuild command or its equivalent.

     $ debuild
  • All binary package entries specified in the debian/binarypackage.install file are generated as binarypackage_version-revision_arch.deb.
[Anmerkung] Anmerkung

The -j option for the debmake command invokes dpkg-depcheck(1) to run debian/rules under strace(1) to obtain library dependencies. Unfortunately, this is very slow. If you know the library package dependencies from other sources such as the SPEC file in the source, you may just run the "debmake …" command without the -j option and run the “debian/rules install” command to check the install paths of the generated files.

The amount of template files generated by the debmake command depends on the -x[01234] option.

[Anmerkung] Anmerkung

None of the existing configuration files are modified by the debmake command.

The debmake command invoked with the -P option pedantically checks auto-generated files for copyright+license text even if they are with permissive license.

This option affects not only the content of the debian/copyright file generated by normal execution, but also the output by the execution with the -k, -c, -cc, and -ccc options.

The debmake command invoked with the -T option additionally prints verbose tutorial comment lines. The lines marked with ### in the template files are part of the verbose tutorial comment lines.