X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=policy.sgml;h=74f94e8c4665de20ad3cd09454f50943c70791b7;hb=6b5ecb49b116555668ebdfc97d9586d5697bb6a8;hp=43cf4d6d140de871594e292d315b69d67aa174f4;hpb=6f23207b0afa0bc3fed73cbfe39a5e1cf650b36f;p=debian%2Fdebian-policy.git diff --git a/policy.sgml b/policy.sgml index 43cf4d6..74f94e8 100644 --- a/policy.sgml +++ b/policy.sgml @@ -24,6 +24,13 @@ Copyright © 1996,1997,1998 Ian Jackson and Christian Schwarz. +
+ These are the copyright dates of the original Policy manual. + Since then, this manual has been updated by many others. No + comprehensive collection of copyright notices for subsequent + work exists. +
+
This manual is free software; you may redistribute it and/or
modify it under the terms of the GNU General Public License
@@ -83,11 +90,10 @@
is used by, a significant number of packages, and
therefore should not be changed without peer
review. Package maintainers can then rely on this
- interfaces not changing, and the package
- management software authors need to ensure
- compatibility with these interface
- definitions. (Control file and changelog file
- formats are examples.)
+ interface not changing, and the package management
+ software authors need to ensure compatibility with
+ this interface definition. (Control file and
+ changelog file formats are examples.)
- 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
+ For more information about the sections and their definitions,
+ see the
- The date must be in RFC822 format
+
@@ -1632,11 +1673,11 @@
- 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
It must start with the line #!/usr/bin/make -f,
so that it can be invoked by saying its name rather than
- invoking
Since an interactive
@@ -2353,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. @@ -2372,6 +2428,8 @@ Package: libc6
Field names are not case-sensitive, but it is usual to capitalize the field names using mixed case as shown below. + Field values are case-sensitive unless the description of the + field says otherwise.
@@ -2435,8 +2493,6 @@ Package: libc6 The syntax and semantics of the fields are described below.
- -
These fields are used by
+ The structure of the Debian changes files is versionned, and + this document describes the format 1.8. +
+
The fields in this file are:
@@ -2510,15 +2571,17 @@ Package: libc6
- Package names must consist only of lower case letters - (a-z), digits (0-9), plus (+) - and minus (-) signs, and periods (.). - They must be at least two characters long and must start - with an alphanumeric character. + Package names (both source and binary, + see ) must consist only of lower case + letters (a-z), digits (0-9), plus + (+) and minus (-) signs, and periods + (.). They must be at least two characters long and + must start with an alphanumeric character.
@@ -2611,8 +2677,8 @@ Package: libc6The package maintainer's name and email address. The name - should come first, then the email address inside angle - brackets <> (in RFC822 format). + must come first, then the email address inside angle + brackets <> (in RFC822 format).
@@ -2629,17 +2695,17 @@ Package: libc6
- List of the names and email addresses of co-maintainers of
- the package, if any. If the package has other maintainers
- beside the one named in the
-
+ List of the names and email addresses of co-maintainers of
+ the package, if any. If the package has other maintainers
+ beside the one named in the
+
Any parser that interprets the Uploaders field in
- The name and email address of the person who changed the
- said package. Usually the name of the maintainer.
- All the rules for the Maintainer field apply here, too.
+ 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
- This field represents how important that it is that the user + This field represents how important it is that the user have the package installed. See .
@@ -2701,11 +2768,9 @@ Package: libc6- Package names must consist only of lower case letters - (a-z), digits (0-9), plus (+) - and minus (-) signs, and periods (.). - They must be at least two characters long and must start - with an alphanumeric character. + Binary package names must follow the same syntax and + restrictions as source package names. See + for the details.
@@ -2717,41 +2782,64 @@ Package: libc6 Architecture field can include the following sets of values:
In the main
+ 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 source package control file
@@ -2771,28 +2859,29 @@ 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 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
- See for information how to get the - architecture for the build process. + See for information on how to get + the architecture for the build process.
@@ -2853,8 +2942,8 @@ Package: libc6
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 the all
- four components may be specified.
@@ -3021,10 +3111,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.
- In a
- The part of the field before the first newline is empty;
- thereafter each line has the name of a binary package and
- the summary description line from that binary package.
- Each line is indented by one space.
+ In a
- You should list all distributions that the - package should be installed into. -
- -- More information is available in the Debian Developer's - Reference, section "The Debian archive". + Others are used for updating stable releases or for + security uploads. More information is available in the + Debian Developer's Reference, section "The Debian + archive".
- 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
@@ -3209,13 +3264,25 @@ Package: libc6
- This field specifies a format revision for the file.
- The most current format described in the Policy Manual
- is version 1.5. The syntax of the
+ In
+ In
- There should be nothing in this field before the first - newline; all the subsequent lines must be indented by at - least one space; blank lines must be represented by a line - consisting only of a space and a full stop. + The first line of the field value (the part on the same line + as Changes:) is always empty. The content of the + field is expressed as continuation lines, with each line + indented by at least one space. Blank lines must be + represented by a line consisting only of a space and a full + stop (.).
@@ -3283,7 +3352,7 @@ Package: libc6 for the most recent version should be returned first, and entries should be separated by the representation of a blank line (the "title" line may also be followed by the - representation of blank line). + representation of a blank line).
@@ -3291,29 +3360,27 @@ Package: libc6- This field is a list of binary packages. + This field is a list of binary packages. Its syntax and + meaning varies depending on the control file in which it + appears.
- When it appears in the
- When it appears in a
- The syntax is a list of binary packages separated by
- commas
- This field appears in the control files of binary
- packages, and in the
- The disk space is represented in kilobytes as a simple - decimal number. + The disk space is given as the integer value of the estimated + installed size in bytes, divided by 1024 and rounded up.
@@ -3339,20 +3408,30 @@ Package: libc6This field contains a list of files with information about each one. The exact information and syntax varies with - the context. In all cases the part of the field - contents on the same line as the field name is empty. The - remainder of the field is one line per file, each line - being indented by one space and containing a number of - sub-fields separated by spaces. + the context. +
+ ++ In all cases, Files is a multiline field. The first line of + the field value (the part on the same line as Files:) + is always empty. The content of the field is expressed as + continuation lines, one line per file. Each line must be + indented by one space and contain a number of sub-fields, + separated by spaces, as described below.
In the
In the
@@ -3383,7 +3468,7 @@ Package: libc6
no new original source archive is being distributed the
.dsc must still contain the Files field
entry for the original source archive
-
+ 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
+ In the
+ This field is similar to the
+ This field is similar to the
- 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.
- If this fails, the package is in a "Failed-Config" + If this fails, the package is in a "Half-Configured" state, or else it remains "Installed".
@@ -4262,6 +4423,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:
+
Note that the binary package relationship fields such as Depends appear in one of the binary package @@ -4428,12 +4604,12 @@ Build-Depends: foo [!i386] | bar [!amd64] be unpacked the pre-dependency can be satisfied if the depended-on package is either fully configured, or even if the depended-on - package(s) are only unpacked or half-configured, - provided that they have been configured correctly at - some point in the past (and not removed or partially - removed since). In this case, both the + package(s) are only unpacked or in the "Half-Configured" + state, provided that they have been configured + correctly at some point in the past (and not removed + or partially removed since). In this case, both the previously-configured and currently unpacked or - half-configured versions must satisfy any version + "Half-Configured" versions must satisfy any version clause in the Pre-Depends field.
@@ -4490,7 +4666,7 @@ Build-Depends: foo [!i386] | bar [!amd64]A package will not be regarded as causing breakage merely because its configuration files are still installed; it must - be at least half-installed. + be at least "Half-Installed".
@@ -4503,17 +4679,29 @@ Build-Depends: foo [!i386] | bar [!amd64]
Normally a Breaks entry will have an "earlier than" version clause; such a Breaks is introduced in the - version of an (implicit or explicit) dependency which - violates an assumption or reveals a bug in earlier versions - of the broken package. This use of Breaks will - inform higher-level package management tools that broken - package must be upgraded before the new one. + version of an (implicit or explicit) dependency which violates + an assumption or reveals a bug in earlier versions of the broken + package, or which takes over a file from earlier versions of the + package named in Breaks. This use of Breaks + will inform higher-level package management tools that the + broken package must be upgraded before the new one.
If the breaking package also overwrites some files from the - older package, it should use Replaces (not - Conflicts) to ensure this goes smoothly. + older package, it should use Replaces to ensure this + goes smoothly. See for a full discussion + of taking over files from other packages, including how to + use Breaks in those cases. +
+ ++ Many of the cases where Breaks should be used were + previously handled with Conflicts + because Breaks did not yet exist. + Many Conflicts fields should now be Breaks. + See for more information about the + differences.
If one package is to be installed, the other must be removed
- first - if the package being installed is marked as
- replacing (see ) the one on the system,
- or the one on the system is marked as deselected, or both
- packages are marked Essential, then
-
A package will not cause a conflict merely because its configuration files are still installed; it must be at least - half-installed. + "Half-Installed".
@@ -4558,12 +4749,52 @@ Build-Depends: foo [!i386] | bar [!amd64]
- A Conflicts entry should almost never have an
- "earlier than" version clause. This would prevent
-
+
+ Conflicts should be used
+
+
+ Be aware that adding Conflicts is normally not the best
+ solution when two packages provide the same files. Depending on
+ the reason for that conflict, using alternatives or renaming the
+ files is often a better approach. See, for
+ example, .
+
+ A Conflicts entry may have an "earlier than" version
+ clause if the reason for the conflict is corrected in a later
+ version of one of the packages. However, normally the presence
+ of an "earlier than" version clause is a sign
+ that Breaks should have been used instead. An "earlier
+ than" version clause in Conflicts
+ prevents
- If a relationship field has a version number attached
- then only real packages will be considered to see whether
- the relationship is satisfied (or the prohibition violated,
- for a conflict or breakage) - it is assumed that a real
- package which provides the virtual package is not of the
- "right" version. So, a Provides field may not
- contain version numbers, and the version number of the
- concrete package which provides a particular virtual package
- will not be looked at when considering a dependency on or
- conflict with the virtual package name.
+ If a relationship field has a version number attached, only real
+ packages will be considered to see whether the relationship is
+ satisfied (or the prohibition violated, for a conflict or
+ breakage). In other words, if a version number is specified,
+ this is a request to ignore all Provides for that
+ package name and consider only real packages. The package
+ manager will assume that a package providing that virtual
+ package is not of the "right" version. A Provides
+ field may not contain version numbers, and the version number of
+ the concrete package which provides a particular virtual package
+ will not be considered when considering a dependency on or
+ conflict with the virtual package name.
- It is likely that the ability will be added in a future
- release of
- If you want to specify which of a set of real packages
- should be the default to satisfy a particular dependency on
- a virtual package, you should list the real package as an
- alternative before the virtual one.
+ If the virtual package represents a facility that can only be
+ provided by one real package at a time, such as
+ the
- Firstly, as mentioned before, it is usually an error for a
- package to contain files which are on the system in
- another package.
+ It is usually an error for a package to contain files which
+ are on the system in another package. However, if the
+ overwriting package declares that it Replaces the one
+ containing the file being overwritten, then
- However, if the overwriting package declares that it
- Replaces the one containing the file being
- overwritten, then
@@ -4677,40 +4952,35 @@ Provides: bar
special argument to allow the package to do any final
cleanup required. See .
- Replaces is a one way relationship -- you have to
- install the replacing package after the replaced
- package.
-
For this usage of Replaces, virtual packages (see ) are not considered when looking at a - Replaces field - the packages declared as being + Replaces field. The packages declared as being replaced must be mentioned by their real names.
- Furthermore, this usage of Replaces only takes - effect when both packages are at least partially on the - system at once, so that it can only happen if they do not - conflict or if the conflict has been overridden. + This usage of Replaces only takes effect when both + packages are at least partially on the system at once. It is + not relevant if the packages conflict unless the conflict has + been overridden.
-- Secondly, Replaces allows the packaging system to + Second, Replaces allows the packaging system to resolve which package should be removed when there is a - conflict - see . This usage only - takes effect when the two packages do conflict, - so that the two usages of this field do not interfere with - each other. + conflict (see ). This usage only takes + effect when the two packages do conflict, so that the + two usages of this field do not interfere with each other.
@@ -4724,7 +4994,8 @@ Conflicts: mail-transport-agent Replaces: mail-transport-agent ensuring that only one MTA can be installed at any one - time. + time. See for more information about this + example.
- 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.
- The development files associated to a shared library need to be
- placed in a package called
-
@@ -5350,10 +5616,10 @@ dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \
- If you are creating a udeb for use in the Debian Installer, you
- will need to specify that
+ The requirement for object files, internal binaries, and
+ libraries, including
+ Applications may also use a single subdirectory under
+
+ The execution time linker/loader, ld*, must still be made + available in the existing location under /lib or /lib64 + since this is part of the ELF ABI for the architecture. +
+The requirement that @@ -5618,6 +5918,15 @@ libbar 1 bar1 (>= 1.0-1) symlinked there, is relaxed to a recommendation.
+ The following directories in the root filesystem are
+ additionally allowed:
- Note, that this applies only to directories below
-
@@ -5730,9 +6041,10 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
- The system-wide mail directory is
Dynamically allocated user accounts. By default @@ -5825,11 +6137,6 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
Reserved.
-@@ -5976,7 +6283,7 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
-@@ -6026,6 +6333,23 @@ rmdir /usr/local/share/emacs 2>/dev/null || true option.
+
+ Be careful of using set -e in
If a service reloads its configuration automatically (as
in the case of
- Note that the same symbol (") is used for the left - and right quotation marks. A grave accent (`) is - not a quote character; neither is an apostrophe - ('). + Note that the same symbol (") is used + for the left and right quotation marks. A grave accent + (`) is not a quote character; neither is an + apostrophe (').
+ Unlike
- The scripts or crontab entries in these directories should + The scripts or crontab entries in these directories should check if all necessary programs are installed before they try to execute them. Otherwise, problems will arise when a package was removed but not purged since configuration files - are kept on the system in this situation.
+ are kept on the system in this situation. + + +
+ Any cron daemon must provide
+
@@ -7010,17 +7369,6 @@ strip --strip-unneeded your-lib
-
- Packages containing shared libraries that may be linked to
- by other packages' binaries, but which for some
- compelling reason can not be installed in
-
An ever increasing number of packages are using
- Shell scripts (
+ Every script should use set -e or check the exit status + of every command.
-
Scripts may assume that
- Packages must not include device files in the package file
- tree.
+ Packages must not include device files or named pipes in the
+ package file tree.
@@ -7270,6 +7624,18 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
+ Named pipes needed by the package must be created in
+ the
@@ -7687,15 +8055,12 @@ endscript
security policy by changing the permissions on a binary:
they can do this by using
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
-
@@ -7875,6 +8207,27 @@ done arch-unknown-linux, since the unknown does not look very good.
+ +
+ A package may specify an architecture wildcard. Architecture
+ wildcards are in the format any (which matches every
+ architecture), os-any, or
+ any-cpu.
@@ -8573,7 +8926,7 @@ name ["syshostname"]:
-@@ -8589,9 +8942,9 @@ name ["syshostname"]:
Customization of programs' X resources may also be
supported with the provision of a file with the same name
- as that of the package placed in the
-
- Packages using the X Window System should not be
- configured to install files under the
-
- Programs that use GNU
- The installation of files into subdirectories
- of
- Packages should install any relevant files into the
- directories
- These libraries used to be all symbolic
- links. However, with X11R7,
- /usr/include/X11 and /usr/lib/X11
- are now real directories, and packages
- should ship their files here instead
- of in /usr/X11R6/{include,lib}/X11.
- x11-common (>= 1:7.0.0) is the package
- responsible for converting these symlinks into
- directories.
-
- Due to limitations in current implementations, all characters
- in the manual page source should be representable in the usual
- legacy encoding for that language, even if the file is
- actually encoded in UTF-8. Safe alternative ways to write many
- characters outside that range may be found in
-
- Your package should call
- It is a good idea to specify a section for the location of
- your program; this is done with the --section
- switch. To determine which section to use, you should look
- at
- You should remove the entries in the
- If
+ Info documents should contain section and directory entry
+ information in the document for the use
+ of
Please note that this does not override the section on
changelog files below, so the file
-
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
- 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
In particular,
-
- 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 .
@@ -9885,23 +10241,23 @@ install-info --quiet --remove /usr/share/info/foobar.infoThe source archive scheme described later is intended to - allow a Debianised source tree with some associated control - information to be reproduced and transported easily. The - Debianised source tree is a version of the original program - with certain files added for the benefit of the - Debianisation process, and with any other changes required + allow a Debian package source tree with some associated + control information to be reproduced and transported easily. + The Debian package source tree is a version of the original + program with certain files added for the benefit of the + packaging process, and with any other changes required made to the rest of the source code and installation scripts.
The extra files created for Debian are in the subdirectory
-
- See . -
- -- 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:
-
- If such a line exists then dpkg-parsechangelog
- will look for the parser as
-
- 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:
-
-
-
- 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. -
-Apply the diff using patch -p0.
Untar the tarfile again if you want a copy of the original - source code alongside the Debianised version.
+ source code alongside the Debian version.
The source packaging tools manage the changes between the
- original and Debianised source using