X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;ds=sidebyside;f=policy.sgml;h=439786cfa687ae6c01b9dd884dc49a962b80b1a8;hb=3233167a3027d2535829ed80e95a674e1a8c5809;hp=e2236bed3234ff82aa371cad655f80110c3536cd;hpb=e72f018ab0719b4efdf430887f2542ab1f00cd36;p=debian%2Fdebian-policy.git diff --git a/policy.sgml b/policy.sgml index e2236be..439786c 100644 --- a/policy.sgml +++ b/policy.sgml @@ -569,8 +569,8 @@ Copyright considerations

- Every package must be accompanied by a verbatim copy of - its copyright and distribution license in the file + Every package must be accompanied by a verbatim copy of its + copyright information and distribution license in the file /usr/share/doc/package/copyright (see for further details).

@@ -689,7 +689,15 @@ ruby, science, shells, sound, tex, text, utils, vcs, video, web, x11, xfce, - zope. + zope. The additional section debian-installer + contains special packages used by the installer and is not used + for normal Debian packages. +

+ +

+ For more information about the sections and their definitions, + see the .

@@ -1610,11 +1618,38 @@

- The date must be in RFC822 format - This is generated by date -R. - ; it must include the time zone specified - numerically, with the time zone name or abbreviation - optionally present as a comment in parentheses. + The date has the following format + This is the same as the format generated by date + -R. + (compatible and with the same semantics of + RFC 2822 and RFC 5322): + day-of-week, dd month yyyy hh:mm:ss +zzzz + where: + + + day-of week is one of: Mon, Tue, Wed, Thu, Fri, Sat, Sun + + + dd is a one- or two-digit day of the month (01-31) + + + month is one of: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, + Sep, Oct, Nov, Dec + + yyyy is the four-digit year (e.g. 2010) + hh is the two-digit hour (00-23) + mm is the two-digit minutes (00-59) + ss is the two-digit seconds (00-60) + + +zzzz or -zzzz is the the time zone offset from Coordinated + Universal Time (UTC). "+" indicates that the time is ahead + of (i.e., east of) UTC and "-" indicates that the time is + behind (i.e., west of) UTC. The first two digits indicate + the hour difference from UTC and the last two digits + indicate the number of additional minutes difference from + UTC. The last two digits must be in the range 00-59. + +

@@ -1638,8 +1673,8 @@ Copyright: debian/copyright

- Every package must be accompanied by a verbatim copy of - its copyright and distribution license in the file + Every package must be accompanied by a verbatim copy of its + copyright information and distribution license in the file /usr/share/doc/package/copyright (see for further details). Also see for further considerations related @@ -1819,21 +1854,28 @@ A package may also provide both of the targets build-arch and build-indep. The build-arch target, if provided, should - perform all the configuration and compilation required - for producing all architecture-dependant binary packages - (those packages for which the body of the - Architecture field in debian/control - is not all). - Similarly, the build-indep target, if - provided, should perform all the configuration and - compilation required for producing all - architecture-independent binary packages + perform all the configuration and compilation required for + producing all architecture-dependant binary packages (those packages for which the body of the - Architecture field in debian/control - is all). + Architecture field in debian/control is + not all). Similarly, the build-indep + target, if provided, should perform all the configuration + and compilation required for producing all + architecture-independent binary packages (those packages + for which the body of the Architecture field + in debian/control is all). The build target should depend on those of the targets build-arch and build-indep that - are provided in the rules file. + are provided in the rules file. + The intent of this split is so that binary-only builds + need not install the dependencies required for + the build-indep target. However, this is not + yet used in practice since dpkg-buildpackage + -B, and therefore the autobuilders, + invoke build rather than build-arch + due to the difficulties in determining whether the + optional build-arch target exists. +

@@ -2362,6 +2404,11 @@ Package: libc6 libc6.

+

+ A paragraph must not contain more than one instance of a + particular field name. +

+

Many fields' values may span several lines; in this case each continuation line must start with a space or a tab. @@ -2446,8 +2493,6 @@ Package: libc6 The syntax and semantics of the fields are described below.

- -

These fields are used by dpkg-gencontrol to generate control files for binary packages (see below), by @@ -2521,15 +2566,17 @@ Package: libc6 Format (mandatory) Source (mandatory) + Binary + Architecture Version (mandatory) Maintainer (mandatory) Uploaders - Binary - Architecture - Build-Depends et al + Homepage Standards-Version (recommended) + Build-Depends et al + Checksums-Sha1 + and Checksums-Sha256 (recommended) Files (mandatory) - Homepage

@@ -2573,6 +2620,8 @@ Package: libc6 Description (mandatory) Closes Changes (mandatory) + Checksums-Sha1 + and Checksums-Sha256 (recommended) Files (mandatory)

@@ -2727,47 +2776,64 @@ Package: libc6 Architecture field can include the following sets of values: - A unique single word identifying a Debian machine - architecture as described in . - - - An architecture wildcard identifying a set of Debian - machine architectures, see . - - all, which indicates an - architecture-independent package. - any, which indicates a package available - for building on any architecture. - source, which indicates a source package. + + A unique single word identifying a Debian machine + architecture as described in . + + + An architecture wildcard identifying a set of Debian + machine architectures, see . + any matches all Debian machine architectures + and is the most frequently used. + + + all, which indicates an + architecture-independent package. + + + source, which indicates a source package. +

In the main debian/control file in the source - package, this field may contain the special value - any, the special value all, or a list of - specific and wildcard architectures separated by spaces. If - any or all appear, that value must be the - entire contents of the field. Most packages will use - either any or all. Specifying a specific - list of architectures is for the minority of cases where a + package, this field may contain the special + value all, the special architecture + wildcard any, or a list of specific and wildcard + architectures separated by spaces. 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, and where possible the program should be made + architectures. Where possible, the program should be made portable instead.

In the source package control file .dsc, this - field may contain either the special value any or a - list of architectures separated by spaces. If a list is given, - it may include (or consist solely of) the special value - all. In other words, in .dsc files - unlike the debian/control, all may occur - in combination with specific architectures. The - Architecture field in the source package control file - .dsc is generally constructed from the - Architecture fields in the - debian/control in the source package. + field may contain either the architecture + wildcard any or a list of architectures and + architecture wildcards separated by spaces. If a list is + given, it may include (or consist solely of) the special + value all. In other words, in .dsc + files unlike the debian/control, all may + occur in combination with specific architectures. + The Architecture field in the source package control + file .dsc is generally constructed from + the Architecture fields in + the debian/control in the source package.

@@ -2787,44 +2853,24 @@ Package: libc6

- Specifying a list of architectures indicates that the source - will build an architecture-dependent package, and will only - work correctly on the listed architectures. If the source - package also builds at least one architecture-independent - package, all will also be included in the list. -

- -

- Specifying a list of architecture wildcards indicates that - the source will build an architecture-dependent package on - the union of the lists of architectures from the expansion - of each specified architecture wildcard, and will only - work correctly on the architectures in the union of the - lists. - As mentioned in the footnote for specifying a list of - architectures, this is for a minority of cases where the - program is not portable. It should not be used for most - packages. Wildcards are not expanded into a list of known - architectures before comparing to the build architecutre. - Instead, the build architecture is matched against any - wildcards and this package is built if any wildcard - matches. - - If the source package also builds at least one - architecture-independent package, all will also be - included in the list. + 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.

In a .changes file, the Architecture - field lists the architecture(s) of the package(s) - currently being uploaded. This will be a list; if the - source for the package is also being uploaded, the special + field lists the architecture(s) of the package(s) currently + being uploaded. This will be a list; if the source for the + package is also being uploaded, the special entry source is also present. all will be present if any architecture-independent packages are being - uploaded. any may never occur in the - Architecture field in the .changes - file. + uploaded. Architecture wildcards such as any must + never occur in the Architecture field in + the .changes file.

@@ -3058,10 +3104,12 @@ Package: libc6 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 (the author of this manual has heard of a - package whose versions went 1.1, 1.2, - 1.3, 1, 2.1, 2.2, - 2 and so forth). + silly orderings. + The author of this manual has heard of a package whose + versions went 1.1, 1.2, 1.3, + 1, 2.1, 2.2, 2 and so + forth. +

@@ -3193,7 +3241,9 @@ Package: libc6 Date

- This field includes the date the package was built or last edited. + This field includes the date the package was built or last + edited. It must be in the same format as the date + in a debian/changelog entry.

@@ -3429,6 +3479,51 @@ Files:

+ + Checksums-Sha1 + and Checksums-Sha256 + +

+ These fields contain a list of files with a checksum and size + for each one. Both Checksums-Sha1 + and Checksums-Sha256 have the same syntax and differ + only in the checksum algorithm used: SHA-1 + for Checksums-Sha1 and SHA-256 + for Checksums-Sha256. +

+ +

+ Checksums-Sha1 and Checksums-Sha256 are + multiline fields. The first line of the field value (the part + on the same line as Checksums-Sha1: + or Checksums-Sha256:) is always empty. The content + of the field is expressed as continuation lines, one line per + file. Each line consists of the checksum, a space, the file + size, a space, and the file name. For example (from + a .changes file): + +Checksums-Sha1: + 1f418afaa01464e63cc1ee8a66a05f0848bd155c 1276 example_1.0-1.dsc + a0ed1456fad61116f868b1855530dbe948e20f06 171602 example_1.0.orig.tar.gz + 5e86ecf0671e113b63388dac81dd8d00e00ef298 6137 example_1.0-1.debian.tar.gz + 71a0ff7da0faaf608481195f9cf30974b142c183 548402 example_1.0-1_i386.deb +Checksums-Sha256: + ac9d57254f7e835bed299926fd51bf6f534597cc3fcc52db01c4bffedae81272 1276 example_1.0-1.dsc + 0d123be7f51e61c4bf15e5c492b484054be7e90f3081608a5517007bfb1fd128 171602 example_1.0.orig.tar.gz + f54ae966a5f580571ae7d9ef5e1df0bd42d63e27cb505b27957351a495bc6288 6137 example_1.0-1.debian.tar.gz + 3bec05c03974fdecd11d020fc2e8250de8404867a8a2ce865160c250eb723664 548402 example_1.0-1_i386.deb + +

+ +

+ In the .dsc file, these fields should list all + files that make up the source package. In + the .changes file, these fields should list all + files being uploaded. The list of files in these fields + must match the list of files in the Files field. +

+ + @@ -3576,15 +3671,26 @@ Files: Controlling terminal for maintainer scripts

- The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - Because these scripts may be executed with standard output - redirected into a pipe for logging purposes, Perl scripts - should set unbuffered output by setting $|=1 so - that the output is printed immediately rather than being - buffered. + Maintainer scripts are not guaranteed to run with a controlling + terminal and may not be able to interact with the user. They + must be able to fall back to noninteractive behavior if no + controlling terminal is available. Maintainer scripts that + prompt via a program conforming to the Debian Configuration + Management Specification (see ) may + assume that program will handle falling back to noninteractive + behavior. +

+ +

+ For high-priority prompts without a reasonable default answer, + maintainer scripts may abort if there is no controlling + terminal. However, this situation should be avoided if at all + possible, since it prevents automated or unattended installs. + In most cases, users will consider this to be a bug in the + package.

+ Exit status @@ -4278,6 +4384,21 @@ Build-Depends: foo [!i386] | bar [!amd64] bar on all other architectures.

+

+ All fields that specify build-time relationships may also be + restricted to a certain set of architectures using architecture + wildcards. The syntax for declaring such restrictions is the + same as declaring restrictions using a certain set of + architectures without architecture wildcards. For example: + +Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] + + is equivalent to foo on architectures using the Linux + kernel and any cpu, bar on architectures using any + kernel and an i386 cpu, and baz on any architecture + using a kernel other than Linux. +

+

Note that the binary package relationship fields such as Depends appear in one of the binary package @@ -4286,23 +4407,6 @@ Build-Depends: foo [!i386] | bar [!amd64] source package section of the control file (which is the first section).

-

- All fields that specify build-time relationships - (Build-Depends, Build-Depends-Indep, - Build-Conflicts and Build-Conflicts-Indep) may also - be restricted to a certain set of architectures using architecture - wildcards. The syntax for declaring such restrictions is the same as - declaring restrictions using a certain set of architectures without - architecture wildcards. - For example: - -Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] - - is equivalent to foo on architectures using the - Linux kernel and any cpu, bar on architectures - using any kernel and an i386 cpu, and baz on - on any architecture using a kernel other than Linux. -

@@ -4698,6 +4802,20 @@ Provides: bar will no longer be listed as "owned" by the old package.

+

+ For example, if a package foo is split + into foo and foo-data + starting at version 1.2-3, foo-data should + have the field + +Replaces: foo (<< 1.2-3) + + in its control file. The package foo + doesn't need any special control fields in this example, + although would generally depend on or + recommend foo-data. +

+

If a package is completely replaced in this way, so that dpkg does not know of any files it still @@ -4788,58 +4906,44 @@ Replaces: mail-transport-agent The dependencies and conflicts they define must be satisfied (as defined earlier for binary packages) in order to invoke the targets in debian/rules, as follows: -

- If you make "build-arch" or "binary-arch", you need - Build-Depends. If you make "build-indep" or - "binary-indep", you need Build-Depends and - Build-Depends-Indep. If you make "build" or "binary", - you need both. -

There is no Build-Depends-Arch; this role is essentially - met with Build-Depends. Anyone building the - build-indep and binary-indep targets - is basically assumed to be building the whole package - anyway and so installs all build dependencies. The - autobuilders use dpkg-buildpackage -B, which - calls build (not build-arch, since it - does not yet know how to check for its existence) and - binary-arch. + met with Build-Depends. Anyone building the + build-indep and binary-indep targets is + assumed to be building the whole package, and therefore + installation of all build dependencies is required.

- The purpose of the original split, I recall, was so that - the autobuilders wouldn't need to install extra packages - needed only for the binary-indep targets. But without a - build-arch/build-indep split, this didn't work, since - most of the work is done in the build target, not in the - binary target. + The autobuilders use dpkg-buildpackage -B, which + calls build, not build-arch since it does + not yet know how to check for its existence, and + binary-arch. The purpose of the original split + between Build-Depends and + Build-Depends-Indep was so that the autobuilders + wouldn't need to install extra packages needed only for the + binary-indep targets. But without a build-arch/build-indep + split, this didn't work, since most of the work is done in + the build target, not in the binary target.

- - Build-Depends, Build-Conflicts + clean, build-arch, and + binary-arch - The Build-Depends and - Build-Conflicts fields must be satisfied when - any of the following targets is invoked: - build, clean, binary, - binary-arch, build-arch, - build-indep and binary-indep. + Only the Build-Depends and Build-Conflicts + fields must be satisfied when these targets are invoked. - Build-Depends-Indep, - Build-Conflicts-Indep + build, build-indep, binary, + and binary-indep - The Build-Depends-Indep and - Build-Conflicts-Indep fields must be - satisfied when any of the following targets is - invoked: build, build-indep, - binary and binary-indep. + The Build-Depends, Build-Conflicts, + Build-Depends-Indep, and + Build-Conflicts-Indep fields must be satisfied when + these targets are invoked.

- - @@ -5111,11 +5215,20 @@ Replaces: mail-transport-agent Development files

- The development files associated to a shared library need to be - placed in a package called - librarynamesoversion-dev, + If there are development files associated with a shared library, + the source package needs to generate a binary development package + named librarynamesoversion-dev, or if you prefer only to support one development version at a - time, libraryname-dev. + time, libraryname-dev. Installing + the development package must result in installation of all the + development files necessary for compiling programs against that + shared library. + This wording allows the development files to be split into + several packages, such as a separate architecture-independent + libraryname-headers, provided that + the development package depends on all the required additional + packages. +

@@ -5893,7 +6006,7 @@ rmdir /usr/local/share/emacs 2>/dev/null || true

- 1000-29999: + 1000-59999:

Dynamically allocated user accounts. By default @@ -5904,11 +6017,6 @@ rmdir /usr/local/share/emacs 2>/dev/null || true

- 30000-59999: - -

Reserved.

- - 60000-64999:

@@ -6055,7 +6163,7 @@ rmdir /usr/local/share/emacs 2>/dev/null || true

- + Writing the scripts

@@ -6105,6 +6213,23 @@ rmdir /usr/local/share/emacs 2>/dev/null || true option.

+

+ Be careful of using set -e in init.d + scripts. Writing correct init.d scripts requires + accepting various error exit statuses when daemons are already + running or already stopped without aborting + the init.d script, and common init.d + function libraries are not safe to call with set -e + in effect + /lib/lsb/init-functions, which assists in writing + LSB-compliant init scripts, may fail if set -e is + in effect and echoing status messages to the console fails, + for example. + . For init.d scripts, it's often easier + to not use set -e and instead check the result of + each command separately. +

+

If a service reloads its configuration automatically (as in the case of cron, for example), the @@ -7202,13 +7327,19 @@ strip --strip-unneeded your-lib language currently used to implement it.

- Shell scripts (sh and bash) - should almost certainly start with set -e so that - errors are detected. Every script should use - set -e or check the exit status of every - command. + Shell scripts (sh and bash) other than + init.d scripts should almost certainly start + with set -e so that errors are detected. + init.d scripts are something of a special case, due + to how frequently they need to call commands that are allowed to + fail, and it may instead be easier to check the exit status of + commands directly. See for more + information about writing init.d scripts. +

+

+ Every script should use set -e or check the exit status + of every command.

-

Scripts may assume that /bin/sh implements the SUSv3 Shell Command Language @@ -7469,6 +7600,8 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq package is purged. + Obsolete configuration files without local changes may be + removed by the package during upgrade.

@@ -7802,15 +7935,12 @@ endscript security policy by changing the permissions on a binary: they can do this by using dpkg-statoverride, as described below. - Ordinary files installed by dpkg (as - opposed to conffiles and other similar objects) - normally have their permissions reset to the distributed - permissions when the package is reinstalled. However, - the use of dpkg-statoverride overrides this - default behavior. If you use this method, you should - remember to describe dpkg-statoverride in - the package documentation; being a relatively new - addition to Debian, it is probably not yet well-known. + Ordinary files installed by dpkg (as + opposed to conffiles and other similar objects) + normally have their permissions reset to the distributed + permissions when the package is reinstalled. However, + the use of dpkg-statoverride overrides this + default behavior. Another method you should consider is to create a group for people allowed to use the program(s) and make any setuid @@ -7942,51 +8072,10 @@ done

If a program needs to specify an architecture specification - string in some place, it should select one of the - strings provided by dpkg-architecture -L. The - strings are in the format - os-arch, though the OS part - is sometimes elided, as when the OS is Linux. -

Currently, the strings are: - i386 ia64 alpha amd64 armeb arm hppa m32r m68k mips - mipsel powerpc ppc64 s390 s390x sh3 sh3eb sh4 sh4eb - sparc darwin-i386 darwin-ia64 darwin-alpha darwin-amd64 - darwin-armeb darwin-arm darwin-hppa darwin-m32r - darwin-m68k darwin-mips darwin-mipsel darwin-powerpc - darwin-ppc64 darwin-s390 darwin-s390x darwin-sh3 - darwin-sh3eb darwin-sh4 darwin-sh4eb darwin-sparc - freebsd-i386 freebsd-ia64 freebsd-alpha freebsd-amd64 - freebsd-armeb freebsd-arm freebsd-hppa freebsd-m32r - freebsd-m68k freebsd-mips freebsd-mipsel freebsd-powerpc - freebsd-ppc64 freebsd-s390 freebsd-s390x freebsd-sh3 - freebsd-sh3eb freebsd-sh4 freebsd-sh4eb freebsd-sparc - kfreebsd-i386 kfreebsd-ia64 kfreebsd-alpha - kfreebsd-amd64 kfreebsd-armeb kfreebsd-arm kfreebsd-hppa - kfreebsd-m32r kfreebsd-m68k kfreebsd-mips - kfreebsd-mipsel kfreebsd-powerpc kfreebsd-ppc64 - kfreebsd-s390 kfreebsd-s390x kfreebsd-sh3 kfreebsd-sh3eb - kfreebsd-sh4 kfreebsd-sh4eb kfreebsd-sparc knetbsd-i386 - knetbsd-ia64 knetbsd-alpha knetbsd-amd64 knetbsd-armeb - knetbsd-arm knetbsd-hppa knetbsd-m32r knetbsd-m68k - knetbsd-mips knetbsd-mipsel knetbsd-powerpc - knetbsd-ppc64 knetbsd-s390 knetbsd-s390x knetbsd-sh3 - knetbsd-sh3eb knetbsd-sh4 knetbsd-sh4eb knetbsd-sparc - netbsd-i386 netbsd-ia64 netbsd-alpha netbsd-amd64 - netbsd-armeb netbsd-arm netbsd-hppa netbsd-m32r - netbsd-m68k netbsd-mips netbsd-mipsel netbsd-powerpc - netbsd-ppc64 netbsd-s390 netbsd-s390x netbsd-sh3 - netbsd-sh3eb netbsd-sh4 netbsd-sh4eb netbsd-sparc - openbsd-i386 openbsd-ia64 openbsd-alpha openbsd-amd64 - openbsd-armeb openbsd-arm openbsd-hppa openbsd-m32r - openbsd-m68k openbsd-mips openbsd-mipsel openbsd-powerpc - openbsd-ppc64 openbsd-s390 openbsd-s390x openbsd-sh3 - openbsd-sh3eb openbsd-sh4 openbsd-sh4eb openbsd-sparc - hurd-i386 hurd-ia64 hurd-alpha hurd-amd64 hurd-armeb - hurd-arm hurd-hppa hurd-m32r hurd-m68k hurd-mips - hurd-mipsel hurd-powerpc hurd-ppc64 hurd-s390 hurd-s390x - hurd-sh3 hurd-sh3eb hurd-sh4 hurd-sh4eb hurd-sparc -

- + string in some place, it should select one of the strings + provided by dpkg-architecture -L. The strings are in + the format os-arch, though the OS + part is sometimes elided, as when the OS is Linux.

@@ -7998,29 +8087,27 @@ done arch-unknown-linux, since the unknown does not look very good.

- - - Architecture Wildcards + + Architecture wildcards -

- A package may specify an architecture wildcard. Architecture - wildcards are in the format os-any and - any-cpu. - Internally, the package system normalizes the GNU triplets and - the Debian arches into Debian arch triplets (which are kind of - inverted GNU triplets), with the first component of the - triplet representing the libc in use. When matching two - Debian arch triplets, whenever an any is found it - matches with anything on the other side, like in: - - gnu-linux-i386 is matched by gnu-linux-any - gnu-kfreebsd-amd64 is matched by any-any-amd64 - - And, for example, any is normalized to - any-any-any. - -

+

+ A package may specify an architecture wildcard. Architecture + wildcards are in the format any (which matches every + architecture), os-any, or + any-cpu. + Internally, the package system normalizes the GNU triplets + and the Debian arches into Debian arch triplets (which are + kind of inverted GNU triplets), with the first component of + the triplet representing the libc and ABI in use, and then + does matching against those triplets. However, such + triplets are an internal implementation detail that should + not be used by packages directly. The libc and ABI portion + is handled internally by the package system based on + the os and cpu. + +

+ @@ -8935,7 +9022,7 @@ name ["syshostname"]: name="Man-Page-HOWTO">, , the examples created by debmake or dh_make, - the helper programs help2man, or the + the helper program help2man, or the directory /usr/share/doc/man-db/examples.

@@ -9175,7 +9262,7 @@ END-INFO-DIR-ENTRY

Every package must be accompanied by a verbatim copy of its - copyright and distribution license in the file + copyright information and distribution license in the file /usr/share/doc/package/copyright. This file must neither be compressed nor be a symbolic link.

@@ -9210,14 +9297,13 @@ END-INFO-DIR-ENTRY

- Packages distributed under the UCB BSD license, the Apache - license (version 2.0), the Artistic license, the GNU GPL - (version 2 or 3), the GNU LGPL (versions 2, 2.1, or 3), and the - GNU FDL (versions 1.2 or 1.3) should refer to the corresponding - files under /usr/share/common-licenses, + Packages distributed under the Apache license (version 2.0), the + Artistic license, the GNU GPL (version 2 or 3), the GNU LGPL + (versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or 1.3) + should refer to the corresponding files + under /usr/share/common-licenses,

In particular, - /usr/share/common-licenses/BSD, /usr/share/common-licenses/Apache-2.0, /usr/share/common-licenses/Artistic, /usr/share/common-licenses/GPL-2, @@ -9227,7 +9313,14 @@ END-INFO-DIR-ENTRY /usr/share/common-licenses/LGPL-3, /usr/share/common-licenses/GFDL-1.2, and /usr/share/common-licenses/GFDL-1.3 - respectively. + respectively. The University of California BSD license is + also included in base-files as + /usr/share/common-licenses/BSD, but given the + brevity of this license, its specificity to code whose + copyright is held by the Regents of the University of + California, and the frequency of minor wording changes, its + text should be included in the copyright file rather than + referencing this file.

rather than quoting them in the copyright file. @@ -9581,9 +9674,9 @@ END-INFO-DIR-ENTRY

- The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - See . + The maintainer scripts are not guaranteed to run with a + controlling terminal and may not be able to interact with + the user. See .

@@ -10055,120 +10148,6 @@ END-INFO-DIR-ENTRY

- - - debian/changelog - -

- See . -

- - Defining alternative changelog formats - - -

- It is possible to use a different format to the standard - one, by providing a parser for the format you wish to - use. -

- -

- In order to have dpkg-parsechangelog run your - parser, you must include a line within the last 40 lines - of your file matching the Perl regular expression: - \schangelog-format:\s+([0-9a-z]+)\W The part in - parentheses should be the name of the format. For - example, you might say: - - @@@ changelog-format: joebloggs @@@ - - Changelog format names are non-empty strings of alphanumerics. -

- -

- If such a line exists then dpkg-parsechangelog - will look for the parser as - /usr/lib/dpkg/parsechangelog/format-name - or - /usr/local/lib/dpkg/parsechangelog/format-name; - it is an error for it not to find it, or for it not to - be an executable program. The default changelog format - is dpkg, and a parser for it is provided with - the dpkg package. -

- -

- The parser will be invoked with the changelog open on - standard input at the start of the file. It should read - the file (it may seek if it wishes) to determine the - information required and return the parsed information - to standard output in the form of a series of control - fields in the standard format. By default it should - return information about only the most recent version in - the changelog; it should accept a - -vversion option to return changes - information from all versions present strictly - after version, and it should then be an - error for version not to be present in the - changelog. -

- -

- The fields are: - - Source - Version (mandatory) - Distribution (mandatory) - Urgency (mandatory) - Maintainer (mandatory) - Date - Changes (mandatory) - -

- -

- If several versions are being returned (due to the use - of -v), the urgency value should be of the - highest urgency code listed at the start of any of the - versions requested followed by the concatenated - (space-separated) comments from all the versions - requested; the maintainer, version, distribution and - date should always be from the most recent version. -

- -

- For the format of the Changes field see - . -

- -

- If the changelog format which is being parsed always or - almost always leaves a blank line between individual - change notes these blank lines should be stripped out, - so as to make the resulting output compact. -

- -

- If the changelog format does not contain date or package - name information this information should be omitted from - the output. The parser should not attempt to synthesize - it or find it from other sources. -

- -

- If the changelog does not have the expected format the - parser should exit with a nonzero exit status, rather - than trying to muddle through and possibly generating - incorrect output. -

- -

- A changelog parser may not interact with the user at - all. -

- - - debian/substvars and variable substitutions