dpkg (1.18.25) stretch; urgency=medium
[dpkg] / man / deb-changes.man
CommitLineData
1479465f
GJ
1.\" dpkg manual page - deb-changes(5)
2.\"
3.\" Copyright © 1995-1996 Ian Jackson <ijackson@chiark.greenend.org.uk>
4.\" Copyright © 2010 Russ Allbery <rra@debian.org>
5.\" Copyright © 2015 Guillem Jover <guillem@debian.org>
6.\"
7.\" This is free software; you can redistribute it and/or modify
8.\" it under the terms of the GNU General Public License as published by
9.\" the Free Software Foundation; either version 2 of the License, or
10.\" (at your option) any later version.
11.\"
12.\" This is distributed in the hope that it will be useful,
13.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
14.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
15.\" GNU General Public License for more details.
16.\"
17.\" You should have received a copy of the GNU General Public License
18.\" along with this program. If not, see <https://www.gnu.org/licenses/>.
19.
20.TH deb\-changes 5 "%RELEASE_DATE%" "%VERSION%" "dpkg suite"
21.nh
22.SH NAME
23deb\-changes \- Debian changes file format
24.
25.SH SYNOPSIS
26.IB filename .changes
27.
28.SH DESCRIPTION
29Each Debian upload is composed of a .changes control file, which
30contains a number of fields.
31Each field begins with a tag, such as
32.B Source
33or
34.B Binary
35(case insensitive), followed by a colon, and the body of the field.
36Fields are delimited only by field tags.
37In other words, field text may be multiple lines in length, but the
38installation tools will generally join lines when processing the body
39of the field (except in case of the multiline fields
40.BR Description ", " Changes ", " Files ", " Checksums\-Sha1
41and
42.BR Checksums\-Sha256 ,
43see below).
44.PP
45The control data might be enclosed in an OpenPGP ASCII Armored signature,
46as specified in RFC4880.
47.
48.SH FIELDS
49.TP
50.BR Format: " \fIformat-version\fP (required)"
51The value of this field declares the format version of the file.
52The syntax of the field value is a version number with a major and minor
53component.
54Backward incompatible changes to the format will bump the major version,
55and backward compatible changes (such as field additions) will bump the
56minor version.
57The current format version is \fB1.8\fP.
58.TP
59.BR Date: " \fIrelease-date\fP (required)"
60The date the package was built or last edited.
61It must be in the same format as the date in a \fBdeb\-changelog\fP(5)
62entry.
63
64The value of this field is usually extracted from the \fIdebian/changelog\fP
65file.
66.TP
67.BR Source: " \fIsource-name\fP [\fB(\fP\fIsource-version\fP\fB)\fP] (required)"
68The name of the source package.
69If the source version differs from the binary version, then the
70\fIsource-name\fP will be followed by a \fIsource-version\fP in parenthesis.
71This can happen when the upload is a binary-only non-maintainer upload.
72.TP
73.BR Binary: " \fIbinary-package-list\fP (required)"
74This folded field is a space-separated list of binary packages to upload.
75.TP
76.BR Architecture: " \fIarch-list\fP"
77Lists the architectures of the files currently being uploaded.
78Common architectures are \fBamd64\fP, \fBarmel\fP, \fBi386\fP, etc.
79Note that the \fBall\fP value is meant for packages that are architecture
80independent.
81If the source for the package is also being uploaded, the special entry
82\fBsource\fP is also present.
83Architecture wildcards must never be present in the list.
84.TP
85.BR Version: " \fIversion-string\fP (required)"
86Typically, this is the original package's version number in whatever form
87the program's author uses.
88It may also include a Debian revision number (for non-native packages).
89The exact format and sorting algorithm are described in
90.BR deb\-version (5).
91.TP
92.BR Distribution: " \fIdistribution\fPs (required)"
93Lists one or more space-separated distributions where this version should
94be installed when it is uploaded to the archive.
95.TP
96.BR Urgency: " \fIurgency\fP (recommended)"
97The urgency of the upload.
98The currently known values, in increasing order of urgency, are:
99.BR low ", " medium ", " high ", " critical " and " emergency .
100.TP
101.BR Maintainer: " \fIfullname-email\fP (required)"
102Should be in the format “Joe Bloggs <jbloggs@example.org>”, and is
103typically the person who created the package, as opposed to the author of
104the software that was packaged.
105.TP
106.BI Changed\-By: " fullname-email"
107Should be in the format “Joe Bloggs <jbloggs@example.org>”, and is
108typically the person who prepared the package changes for this release.
109.TP
110.BR Description: " (recommended)"
111.TQ
112.RB " \fIbinary-package-name\fP " \fB\-\fP " \fIbinary-package-summary\fP"
113This multiline field contains a list of binary package names followed by
114a space, a dash (‘\fB\-\fP’) and their possibly truncated short
115descriptions.
116.TP
117.BI Closes: " bug-number-list"
118A space-separated list of bug report numbers that have been resolved with
119this upload.
120The distribution archive software might use this field to automatically
121close the referred bug numbers in the distribution bug tracking system.
122.TP
123.B Binary\-Only: yes
124This field denotes that the upload is a binary-only non-maintainer build.
125It originates from the \fBbinary\-only=yes\fP key/value from the changelog
126matadata entry.
127.TP
128.BI Built\-For\-Profiles: " profile-list"
129This field specifies a whitespace separated list of build profiles that
130this upload was built with.
131.TP
132.BR Changes: " (required)"
133.TQ
134.I " changelog-entries"
135This multiline field contains the concatenated text of all changelog
136entries that are part of the upload.
137To make this a valid multiline field empty lines are replaced with a
138single full stop (‘.’) and all lines are indented by one space
139character.
140The exact content depends on the changelog format.
141.TP
142.BR Files: " (required)"
143.TQ
144.RI " " md5sum " " size " " section " " priority " " filename
145This multiline field contains a list of files with an md5sum, size, section
146and priority for each one.
147
148The first line of the field value (the part on the same line as the field
149name followed by a colon) is always empty.
150The content of the field is expressed as continuation lines, one line per file.
151Each line consists of space-separated entries describing the file:
152the md5sum, the file size, the file section, the file priority, and
153the file name.
154
155This field lists all files that make up the upload.
156The list of files in this field must match the list of files in the
157other related \fBChecksums\fP fields.
158.TP
159.BR Checksums\-Sha1: " (required)"
160.TQ
161.BR Checksums\-Sha256: " (required)"
162.TQ
163.RI " " checksum " " size " " filename
164These multiline fields contain a list of files with a checksum and size
165for each one.
166These fields have the same syntax and differ only in the checksum algorithm
167used: SHA-1 for \fBChecksums\-Sha1\fP and SHA-256 for \fBChecksums\-Sha256\fP.
168
169The first line of the field value (the part on the same line as the field
170name followed by a colon) is always empty.
171The content of the field is expressed as continuation lines, one line per file.
172Each line consists of space-separated entries describing the file:
173the checksum, the file size, and the file name.
174
175These fields list all files that make up the upload.
176The list of files in these fields must match the list of files in the
177\fBFiles\fP field and the other related \fBChecksums\fP fields.
178.
179.\" .SH EXAMPLE
180.\" .RS
181.\" .nf
182.\"
183.\" .fi
184.\" .RE
185.
186.SH BUGS
187The \fBFiles\fP field is inconsistent with the other \fBChecksums\fP fields.
188The \fBChange\-By\fP and \fBMaintainer\fP fields have confusing names.
189The \fBDistribution\fP field contains information about what is commonly
190referred to as a suite.
191.SH SEE ALSO
192.BR deb\-src\-control (5),
193.BR deb\-version (5).