If you are asking your sponsor to upload it, you should document changes more comprehensively, including all packaging related ones, to help reviewing your package. The debmake command creates the initial template file with the upstream package version and the Debian revision. The debchange command alias dch is commonly used to edit this. Debian takes the copyright and license matters very seriously. See Section 6. The debmake command creates the initial DEP-5 compatible template file by scanning the entire source tree.
It uses an internal license checker to classify each license text. Unless specifically requested to be pedantic with the -P option, the debmake command skips reporting for auto-generated files with permissive licenses to be practical.
If you find issues with this license checker, please file a bug report to the debmake package with the problematic part of text containing the copyright and license. In order to do this within reasonable time, it only picks the first section which looks like copyright and license claims.
So its license assignment may not be optimal. Please also use other tools such as licensecheck. You are highly encouraged to check the license status with the licensecheck 1 command and, as needed, with your manual code review. The native Debian package see Section 5.
There are several methods to prepare a series of -p1 patches. The automatic patch generation by the dpkg-buildpackage. Wherever these patches come from, it is a good idea to tag them with a DEP-3 compatible header.
The dgit package offers an alternative git integration tool with the Debian package archive. If you wish to keep the source tree unmodified for example, for use in Section 5. The patches should apply cleanly when using the dpkg-source command. The dquilt command see Section 3. You can normalize the patches by the dquilt command. There is one advantage of using the dpkg-source command over the dquilt command.
There are sets of files:. Otherwise, use the hkp keyserver and check it via your web of trust. Now the uscan command will check the authenticity of the package using the GPG signature. Debian takes software freedom seriously and follows the DFSG.
The non- DFSG components in the upstream source tarball can be easily removed when the uscan command is used to update the Debian package.
Run the uscan command to download the new upstream tarball. Even an upstream source without its build system can be packaged just by using these files. See Section 8. The " -x[] " superscript notation that appears in the following list indicates the minimum value for the debmake -x option that will generate the associated template file.
The bash-completion package is required for both build and user environments. Previously, this set the debhelper compatibility level. List directories to be created in binarypackage. Use this only when you run into trouble.
Installed as the doc-base control file in binarypackage. List documentation files to be installed in binarypackage. If this exists, it functions as the configuration file for the gbp command. See gbp. List info files to be installed in binarypackage. These are copyright file examples generated by the debmake command. Use these as the reference for making the copyright file.
List pairs of source and destination files to be symlinked. Each pair should be put on its own line, with the source and destination separated by whitespace. This file is used to suppress erroneous lintian diagnostics. These are manpage template files generated by the debmake command. Please rename these to appropriate file names and update their contents.
Debian Policy requires that each program, utility, and function should have an associated manual page included in the same package. Manual pages are written in nroff 1. If you are new to making a manpage, use manpage. See menufile 5 for its format. Collection of -p1 patch files which are applied to the upstream source before building the source.
See dpkg-source 1 , Section 3. No patch files are generated by the debmake command. See also debconf-devel 7 and 3. These files are not installed, but will be scanned by the lintian command to provide overrides for the source package. The dpkg-source command uses this content as its options. Notable options are:. This is not included in the generated source package and is meant to be committed to the VCS of the maintainer. The symbols files, if present, are passed to the dpkg-gensymbols command to be processed and installed.
The control file for the uscan command to download the latest upstream version. This control file may be configured to verify the authenticity of the tarball using its GPG signature see Section 5. A simple example is given in Section 4. Normally, this customization involves a combination of the following:. Simple examples are given in Section 4. You should address the root cause of the Debian packaging problem by the least invasive way. The generated package shall be more robust for future upgrades in this way.
Send the patch addressing the root cause to the upstream maintainer if it is useful to the upstream. Typically, Git is used as the VCS to record the Debian packaging activity with the following branches.
You may also track the upstream VCS data with a branch different from the upstream branch to ease cherry-picking of patches. You may not wish to keep up with creating the -p1 patch files for all upstream changes needed. You can record the Debian packaging activity with the following branches. This approach can be adopted for any VCS tools. Since this approach merges all changes into a merged patch, it is desirable to keep the VCS data publicly accessible.
There are a few cases which cause the inclusion of undesirable contents in the generated Debian source package. Normally, the -i and -I options set in Section 3.
Here, the -i option is aimed at the non-native package while the -I is aimed at the native package. This is also useful for auto-generated files.
The problem of extraneous contents can be fixed by restoring the source tree by committing the source tree to the VCS before the first build. For excluding the config. So it saves you having to make a backup of the unmodified file just to be able to restore it before the next build. This may be useful when the local non-standard VCS files interfere with your packaging. If, for example, the source package of a native package needs files with the file extension.
Upstream build systems are designed to go through several steps to install generated binary files to the system from the source distribution. Three typical build systems are described here. The situation of other build systems are very similar to these since debhelper 7 the does most of the work and helps you build a Debian package.
Before attempting to make a Debian package, you should become familiar with the upstream build system of the upstream source code and try to build it. The generated tarball contains not only the pristine upstream VCS contents but also other generated files. The package maintainer needs to take care of steps 2 to 4 at least. The package maintainer may wish to take care all steps 1 to 4.
This rebuilds all auto-generated files to the latest version and provides better support for porting to the newer architectures. The upstream tarball contains no auto-generated files and is generated by the tar command after step 1. The package maintainer needs to take care of step 2. These days, most upstream maintainers of Python packages use setuptools with wheel. Since setuptools is an extension of distutils, this step 2 works as expected even if setup.
If you wish to learn more on Python3, distutils , and setuptools , please see:. The name of such a debug package normally has the -dbgsym suffix. Packaging library software requires you to perform much more work than usual. Here are some reminders for packaging library software:. Escaping the Dependency Hell [16]. Debian Library Packaging guide [17]. The symbols support in dpkg introduced in Debian lenny 5.
If the dpkg-gensymbols command warns about some new symbols:. If the dpkg-gensymbols command does not warn about new symbols:. When you package a new library package version which affects other packages, you must file a transition bug report against the release. Release team has the transition tracker.
See Transitions. Please make sure to rename binary packages as in Section 5. The debconf package enables us to configure packages during their installation in 2 main ways:.
All user interactions for the package installation must be handled by this debconf system using the following files. Multiarch support for cross-architecture installation of binary packages particularly i and amd64 , but also other combinations in the dpkg and apt packages introduced in Debian wheezy 7.
Debian policy requires following Filesystem Hierarchy Standard. For other packages with non-supported build systems, you need to manually adjust the install path as follows. All files installed simultaneously as the multiarch package to the same file path should have exactly the same file content. You must be careful with differences generated by the data byte order and by the compression algorithm. The --libexecdir option of the. It is always a good idea to follow GNU unless it conflicts with the Debian policy.
For shared library files in another path, the GCC option -l must be set by the pkg-config command to make them load properly. The use of the file path containing packagename enables having more than 2 development libraries simultaneously installed on a system. The pkg-config program is used to retrieve information about installed libraries in the system. Table 5. The compiler hardening support spreading for Debian jessie 8.
When the autopkgtest command is run, the generated binary packages are installed and tested in the virtual environment according to this file.
Debian packaging practices are moving target. Debian cares about supporting new ports or flavours. Already have an account? Sign in to comment.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Package: com. Description: An example package. This longer description will load when a depiction URL is not specified.
Author: Ms. Maintainer: Example, Inc. Section: Addons SpringBoard. Pre-Depends: com. Depends: com. They consist of a single paragraph, possibly surrounded by a PGP signature. This document describes format 1. Date mandatory. Binary mandatory. Distribution mandatory. Urgency recommended.
Changes mandatory. In a binary package control file or a. The field itself may be omitted from a binary package control file when the source package has the same name and version as the binary package. They must be at least two characters long and must start with an alphanumeric character.
See The maintainer of a package for additional requirements and information about package maintainers. List of the names and email addresses of co-maintainers of the package, if any. If the package has other maintainers besides the one named in the Maintainer field , their names and email addresses should be listed here. The format of each entry is the same as that of the Maintainer field, and multiple entries must be comma separated.
This is normally an optional field, but if the Maintainer control field names a group of people and a shared email address, the Uploaders field must be present and must contain at least one human with their personal email address. The name and email address of the person who prepared this version of the package, usually a maintainer. The syntax is the same as for the Maintainer field.
This field specifies an application area into which the package has been classified. See Sections. It also gives the default for the same field in the binary packages. This field represents how important it is that the user have the package installed.
See Priorities. Binary package names must follow the same syntax and restrictions as source package names. See Source for the details. Depending on context and the control file used, the Architecture field can include the following sets of values:. A unique single word identifying a Debian machine architecture as described in Architecture specification strings. An architecture wildcard identifying a set of Debian machine architectures, see Architecture wildcards.
If all or any appears, that value must be the entire contents of the field. Most packages will use either all or any. Specifying a specific list of architectures indicates that the source will build an architecture-dependent package only on architectures included in the list. Specifying a list of architecture wildcards indicates that the source will build an architecture-dependent package on only those architectures that match any of the specified architecture wildcards.
Specifying a list of architectures or architecture wildcards other than any is for the minority of cases where a program is not portable or is not useful on some architectures. Where possible, the program should be made portable instead. In the Debian source control file. When the list contains the architecture wildcard any , the only other value allowed in the list is all.
The list may include or consist solely of the special value all. In other words, in. The Architecture field in the Debian source control file. The produced binary package s will be specific to whatever the current build architecture is. Specifying only all indicates that the source package will only build architecture-independent packages.
The set of produced binary packages will include at least one architecture-dependent package and one architecture-independent package. Specifying a list of architectures or architecture wildcards indicates that the source will build an architecture-dependent package, and will only work correctly on the listed or matching architectures. If the source package also builds at least one architecture-independent package, all will also be included in the list.
This will be a list; if the source for the package is also being uploaded, the special entry source is also present. Architecture wildcards such as any must never occur in the Architecture field in the.
This is a boolean field which may occur only in the control file of a binary package or in a per-package fields paragraph of a source package control file. If set to yes then the package management system will refuse to remove the package upgrading and replacing it is still possible.
The other possible value is no , which is the same as not having the field at all. Their syntax and semantics are described in Declaring relationships between packages. The most recent version of the standards the policy manual and associated texts with which the package complies. See Standards conformance.
The version number has four components: major and minor version number and major and minor patch level. When the standards change in a way that requires every package to change the major number will be changed. Significant changes that will require work in many packages will be signaled by a change to the minor number.
The major patch level will be changed for any change to the meaning of the standards, however small; the minor patch level will be changed when only cosmetic, typographical or other edits are made which neither change the meaning of the document nor affect the contents of packages.
Thus only the first three components of the policy version are significant in the Standards-Version control field, and so either these three components or all four components may be specified.
The version number of a package. This is a single generally small unsigned integer. It may be omitted, in which case zero is assumed. Epochs can help when the upstream version numbering scheme changes, but they must be used with care. You should not change the epoch, even in experimental, without getting consensus on debian-devel first. This is the main part of the version number. This part of the version number specifies the version of the Debian package based on the upstream version.
This format represents the case where a piece of software was written specifically to be a Debian package, where the Debian package source must always be identical to the pristine source and therefore no revision indication is required.
First the initial part of each string consisting entirely of non-digit characters is determined. These two parts one of which may be empty are compared lexically. If a difference is found it is returned. The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters and so that a tilde sorts before anything, even the end of a part.
Then the initial part of the remainder of each string which consists entirely of digit characters is determined. The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison. For these purposes an empty string which can only occur at the end of one or both version strings being compared counts as zero. These two steps comparing and removing initial non-digit strings and initial digit strings are repeated until a difference is found or both strings are exhausted.
Note that the purpose of epochs is to cope with situations where the upstream version numbering scheme changes and to allow us to leave behind serious mistakes. If you think that increasing the epoch is the right solution, you should consult debian-devel and get consensus before doing so even in experimental.
Epochs should not be used when a package needs to be rolled back. Eventually, when we upload upstream 2. Epochs are also not intended to cope with version numbers containing strings of letters which the package management system cannot interpret such as ALPHA or pre- , or with silly orderings.
In a source or binary control file, the Description field contains a description of the binary package, consisting of two parts, the synopsis or the short description, and the long description. It is a multiline field with the following format:. Those starting with a single space are part of a paragraph. Successive lines of this form will be word-wrapped when displayed.
The leading space will usually be stripped off. The line must contain at least one non-whitespace character. Those starting with two or more spaces. These will be displayed verbatim. If it can they will be allowed to trail off to the right.
None, one or two initial spaces may be deleted, but the number of spaces deleted from each line will be the same so that you can have indenting work correctly, for example. Those containing a single space followed by a single full stop character. These are rendered as blank lines. This is the only way to get a blank line.
Those containing a space, a full stop and some more characters. These are for future expansion. Do not use them. See The description of a package for further information on this. For this case, the first line of the field value the part on the same line as Description: is always empty. It is a multiline field, with one line per package. Each line is indented by one space and contains the name of a binary package, a space, a hyphen - , a space, and the short description line from that package.
Valid distributions are determined by the archive maintainers. Migration of packages to other distributions is handled outside of the upload process. This field includes the date the package was built or last edited. The syntax of the field value is the same as that of a package version number except that no epoch or Debian revision is allowed. The format described in this document is 1. The field value is used by programs acting on a source package to interpret the list of files in the source package and determine how to unpack it.
The syntax of the field value is a numeric major revision, a period, a numeric minor revision, and then an optional subtype after whitespace, which if specified is an alphanumeric word in parentheses.
The subtype is optional in the syntax but may be mandatory for particular source format revisions. This is a description of how important it is to upgrade to this version from previous ones. It consists of a single keyword taking one of the values low , medium , high , emergency , or critical 12 not case-sensitive followed by an optional commentary separated by a space which is usually in parentheses.
0コメント