This manual is distributed via the Debian package
-
The current version of this document is also available from
the Debian web mirrors at
+ The aims of this are:
+
+
+
@@ -302,32 +309,14 @@ of the Debian distribution, although we support their use and provide infrastructure for them (such as our bug-tracking system and mailing lists). This Debian Policy Manual applies - to these packages as well.
+ to these packages as well. + -
- The aims of this section are:
-
-
-
-
- The Debian Free Software Guidelines (DFSG) form our
- definition of "free software". These are:
+ The Debian Free Software Guidelines (DFSG) form our
+ definition of "free software". These are:
Every package in main and non-US/main must comply with the DFSG (Debian Free Software @@ -571,140 +565,151 @@ server as well.
- Every package must be accompanied by a verbatim copy of
- its copyright and distribution license in the file
-
- We reserve the right to restrict files from being included
- anywhere in our archives if
-
-
+ Every package must be accompanied by a verbatim copy of
+ its copyright and distribution license in the file
+
+ We reserve the right to restrict files from being included
+ anywhere in our archives if
+
+
-
- Programs whose authors encourage the user to make - donations are fine for the main distribution, provided - that the authors do not claim that not donating is - immoral, unethical, illegal or something similar; in such - a case they must go in non-free.
++ Programs whose authors encourage the user to make + donations are fine for the main distribution, provided + that the authors do not claim that not donating is + immoral, unethical, illegal or something similar; in such + a case they must go in non-free. +
-- Packages whose copyright permission notices (or patent - problems) do not even allow redistribution of binaries - only, and where no special permission has been obtained, - must not be placed on the Debian FTP site and its mirrors - at all.
++ Packages whose copyright permission notices (or patent + problems) do not even allow redistribution of binaries + only, and where no special permission has been obtained, + must not be placed on the Debian FTP site and its mirrors + at all. +
-- Note that under international copyright law (this applies - in the United States, too), no distribution or - modification of a work is allowed without an explicit - notice saying so. Therefore a program without a copyright - notice is copyrighted and you may not do anything - to it without risking being sued! Likewise if a program - has a copyright notice but no statement saying what is - permitted then nothing is permitted.
++ Note that under international copyright law (this applies + in the United States, too), no distribution or + modification of a work is allowed without an explicit + notice saying so. Therefore a program without a copyright + notice is copyrighted and you may not do anything + to it without risking being sued! Likewise if a program + has a copyright notice but no statement saying what is + permitted then nothing is permitted. +
-- Many authors are unaware of the problems that restrictive - copyrights (or lack of copyright notices) can cause for - the users of their supposedly-free software. It is often - worthwhile contacting such authors diplomatically to ask - them to modify their license terms. However, this can be a - politically difficult thing to do and you should ask for - advice on the debian-legal mailing list first, as - explained below. -
++ Many authors are unaware of the problems that restrictive + copyrights (or lack of copyright notices) can cause for + the users of their supposedly-free software. It is often + worthwhile contacting such authors diplomatically to ask + them to modify their license terms. However, this can be a + politically difficult thing to do and you should ask for + advice on the debian-legal mailing list first, as + explained below. +
-
- When in doubt about a copyright, send mail to
-
+ When in doubt about a copyright, send mail to
+
- The packages in the sections main, - contrib and non-free are grouped further - into subsections to simplify handling. -
+
- The section and subsection for each package should be
- specified in the package's Section control
- record. However, the maintainer of the Debian archive
- may override this selection to ensure the consistency of
- the Debian distribution. The Section field
- should be of the form:
-
+ The packages in the sections main,
+ contrib and non-free are grouped further
+ into subsections to simplify handling.
+
+ The section and subsection for each package should be
+ specified in the package's Section control
+ record (see ).
+ However, the maintainer of the Debian archive
+ may override this selection to ensure the consistency of
+ the Debian distribution. The Section field
+ should be of the form:
+
-
+
+
-
- The Debian archive maintainers provide the authoritative - list of subsections. At present, they are: - admin, base, comm, - contrib, devel, doc, - editors, electronics, embedded, - games, gnome graphics, - hamradio, interpreters, kde, - libs, libdevel, mail, - math, misc, net, news, - non-US, non-free, oldlibs, - otherosfs, perl, python - science, shells, - sound, tex, text, - utils, web, x11. -
- -+ The Debian archive maintainers provide the authoritative + list of subsections. At present, they are: + admin, base, comm, + contrib, devel, doc, + editors, electronics, embedded, + games, gnome graphics, + hamradio, interpreters, kde, + libs, libdevel, mail, + math, misc, net, news, + non-US, non-free, oldlibs, + otherosfs, perl, python + science, shells, + sound, tex, text, + utils, web, x11. +
+Each package should have a priority value, which is - included in the package's control record. This - information is used by the Debian package management tools - to separate high-priority packages from less-important - packages.
+ included in the package's control record + (see ). + This information is used by the Debian package management tools to + separate high-priority packages from less-important packages. +The following priority levels are recognised by the @@ -778,512 +783,616 @@
+ The Debian GNU/Linux distribution is based on the Debian
+ package management system, called
- The Debian GNU/Linux distribution is based on the Debian
- package management system, called
+ The package name is included in the control field + Package, the format of which is described + in . + The package name is also included as a part of the file name + of the .deb file. +
+- Every package must have a name that's unique within the Debian - archive.
++ Every package has a version number recorded in its + Version control file field, described in + . +
-- 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. -
++ The package management system imposes an ordering on version + numbers, so that it can tell whether packages are being up- or + downgraded and so that package system front end applications + can tell whether a package it finds available is newer than + the one installed on the system. The version number format + has the most significant parts (as far as comparison is + concerned) at the beginning. +
-- The package name is part of the file name of the - .deb file and is included in the control field - information. -
-+ If an upstream package has problematic version numbers they + should be converted to a sane form for use in the + Version field. +
- Every package must have a Debian maintainer (the - maintainer may be one person or a group of people - reachable from a common email address, such as a mailing - list). The maintainer is responsible for ensuring that - the package is placed in the appropriate distributions. -
+- The maintainer must be specified in the - Maintainer control field with their correct name - and a working email address. If one person maintains - several packages, he/she should try to avoid having - different forms of their name and email address in - the Maintainer fields of those packages. + In general, Debian packages should use the same version + numbers as the upstream sources.
- If the maintainer of a package quits from the Debian
- project, "Debian QA Group"
-
- Every Debian package must have an extended description - stored in the appropriate field of the control record.
+ To prevent having to use epochs for every new upstream + version, the version number should be changed to the + following format in such cases: "19960501", "19961224". It + is up to the maintainer whether he/she wants to bother the + upstream maintainer to change the version numbers upstream, + too. +- The description should be written so that it gives the - system administrator enough information to decide whether - to install the package. This description should not just - be copied verbatim from the program's documentation. - Instructions for configuring or using the package should - not be included (that is what installation scripts, - manual pages, info files, etc., are for). Copyright - statements and other administrivia should not be included - either (that is what the copyright file is for). + Note that other version formats based on dates which are + parsed correctly by the package management system should + not be changed.
-- Every package must specify the dependency information - about other packages that are required for the first to - work correctly.
++ Every package must have a Debian maintainer (the + maintainer may be one person or a group of people + reachable from a common email address, such as a mailing + list). The maintainer is responsible for ensuring that + the package is placed in the appropriate distributions. +
-- For example, a dependency entry must be provided for any - shared libraries required by a dynamically-linked executable - binary in a package.
++ The maintainer must be specified in the + Maintainer control field with their correct name + and a working email address. If one person maintains + several packages, he/she should try to avoid having + different forms of their name and email address in + the Maintainer fields of those packages. +
-- Packages are not required to declare any dependencies they - have on other packages which are marked Essential - (see below), and should not do so unless they depend on a - particular version of that package.
++ The format of the Maintainer control field is + described in . +
-- Sometimes, a package requires another package to be installed - and configured before it can be installed. In this - case, you must specify a Pre-Depends entry for - the package.
+
+ If the maintainer of a package quits from the Debian
+ project, "Debian QA Group"
+
- You should not specify a Pre-Depends entry for a - package before this has been discussed on the - debian-devel mailing list and a consensus about - doing that has been reached.
+ Every Debian package must have an extended description + stored in the appropriate field of the control record. + The technical information about the format of the + Description field is in . +
-+ The description should describe the package (the program) to a + user (system administrator) who has never met it before so that + they have enough information to decide whether they want to + install it. This description should not just be copied verbatim + from the program's documentation. +
-- Sometimes, there are several packages which offer - more-or-less the same functionality. In this case, it's - useful to define a virtual package whose name - describes that common functionality. (The virtual - packages only exist logically, not physically; that's why - they are called virtual.) The packages with this - particular function will then provide the virtual - package. Thus, any other package requiring that function - can simply depend on the virtual package without having to - specify all possible packages individually.
++ Put important information first, both in the synopsis and + extended description. Sometimes only the first part of the + synopsis or of the description will be displayed. You can + assume that there will usually be a way to see the whole + extended description. +
-- All packages should use virtual package names where - appropriate, and arrange to create new ones if necessary. - They should not use virtual package names (except privately, - amongst a cooperating group of packages) unless they have - been agreed upon and appear in the list of virtual package - names. (See also )
++ The description should also give information about the + significant dependencies and conflicts between this package + and others, so that the user knows why these dependencies and + conflicts have been declared. +
+ ++ Instructions for configuring or using the package should + not be included (that is what installation scripts, + manual pages, info files, etc., are for). Copyright + statements and other administrivia should not be included + either (that is what the copyright file is for). +
+ +
- The latest version of the authoritative list of virtual
- package names can be found in the debian-policy package.
- It's also available from the Debian web mirrors at
-
- The procedure for updating the list is described in the preface - to the list. + Do not include the package name in the synopsis line. The + display software knows how to display this already, and you + do not need to state it. Remember that in many situations + the user may only see the synopsis line - make it as + informative as you can.
- The base system is a minimum subset of the Debian - GNU/Linux system that is installed before everything else - on a new system. Thus, only very few packages are allowed - to go into the base section to keep the required - disk usage very small.
+ Do not try to continue the single line synopsis into the + extended description. This will not work correctly when + the full description is displayed, and makes no sense + where only the summary (the single line synopsis) is + available. +- Most of these packages will have the priority value - required or at least important, and many - of them will be tagged essential (see below).
+ The extended description should describe what the package + does and how it relates to the rest of the system (in terms + of, for example, which subsystem it is which part of). + +
+ The description field needs to make sense to anyone, even
+ people who have no idea about any of the things the
+ package deals with.
- Some packages are tagged essential. (They have - Essential: yes in their package control record.) - This flag is used for packages that are essential - for a system.
++ Every package must specify the dependency information + about other packages that are required for the first to + work correctly. +
-
- Since these packages cannot be easily removed (one has to
- specify an extra force option to
-
+ For example, a dependency entry must be provided for any + shared libraries required by a dynamically-linked executable + binary in a package. +
-- Since dpkg will not prevent upgrading of other packages - while an essential package is in an unconfigured - state, all essential packages must supply all of - their core functionality even when unconfigured. If the - package cannot satisfy this requirement it must not be - tagged as essential, and any packages depending on this - package must instead have explicit dependency fields as - appropriate. -
++ Packages are not required to declare any dependencies they + have on other packages which are marked Essential + (see below), and should not do so unless they depend on a + particular version of that package. +
-- You must not tag any packages essential before - this has been discussed on the debian-devel - mailing list and a consensus about doing that has been - reached. -
-+ Sometimes, a package requires another package to be installed + and configured before it can be installed. In this + case, you must specify a Pre-Depends entry for + the package. +
-
- The Debian install process allows the user to choose from
- a number of common tasks which a Debian system can be used to
- perform. Selecting a task with
+ You should not specify a Pre-Depends entry for a + package before this has been discussed on the + debian-devel mailing list and a consensus about + doing that has been reached. +
-- This set of packages is all available packages which have the - name of the selected task in the Task field of their - control file. The format of this field is a list of tasks, - separated by commas. -
++ The format of the package interrelationship control fields is + described in . +
+- You should not tag any packages as belonging to a task - before this has been discussed on the - debian-devel mailing list and a consensus about - doing that has been reached. -
+- For third parties (and historical reasons), tasksel also - supports constructing tasks based on task - packages. These are packages whose names begin with - task-. Task packages should not be included in the - Debian archive. -
- ++ Sometimes, there are several packages which offer + more-or-less the same functionality. In this case, it's + useful to define a virtual package whose name + describes that common functionality. (The virtual + packages only exist logically, not physically; that's why + they are called virtual.) The packages with this + particular function will then provide the virtual + package. Thus, any other package requiring that function + can simply depend on the virtual package without having to + specify all possible packages individually. +
-+ All packages should use virtual package names where + appropriate, and arrange to create new ones if necessary. + They should not use virtual package names (except privately, + amongst a cooperating group of packages) unless they have + been agreed upon and appear in the list of virtual package + names. (See also ) +
-
- The package installation scripts should avoid producing
- output which it is unnecessary for the user to see and
- should rely on
+ The latest version of the authoritative list of virtual
+ package names can be found in the debian-policy package.
+ It is also available from the Debian web mirrors at
+
- Errors which occur during the execution of an installation - script must be checked and the installation must not - continue after an error. -
++ The procedure for updating the list is described in the preface + to the list. +
-- Note that in general applies to package - maintainer scripts, too. -
+
- You should not use
- All packages which supply an instance of a common command
- name (or, in general, filename) should generally use
-
+ The base system is a minimum subset of the Debian + GNU/Linux system that is installed before everything else + on a new system. Thus, only very few packages are allowed + to go into the base section to keep the required + disk usage very small. +
++ Most of these packages will have the priority value + required or at least important, and many + of them will be tagged essential (see below). +
+
- Package maintainer scripts may prompt the user if
- necessary. Prompting may be accomplished by
- hand
- 6% of Debian packages [see
- With this increasing number of packages using
-
+ Some packages are tagged essential for a system + using the Essential control file field. + The format of the Essential control field is + described in . +
-
- The Debian Configuration management specification is included
- in the
+ Since these packages cannot be easily removed (one has to
+ specify an extra force option to
+
- Packages which use the Debian Configuration management
- specification may contain an additional
-
+ Since dpkg will not prevent upgrading of other packages + while an essential package is in an unconfigured + state, all essential packages must supply all of + their core functionality even when unconfigured. If the + package cannot satisfy this requirement it must not be + tagged as essential, and any packages depending on this + package must instead have explicit dependency fields as + appropriate. +
-
- Packages should try to minimize the amount of prompting
- they need to do, and they should ensure that the user
- will only ever be asked each question once. This means
- that packages should try to use appropriate shared
- configuration files (such as
+ You must not tag any packages essential before + this has been discussed on the debian-devel + mailing list and a consensus about doing that has been + reached. +
+ -
- It also means that an upgrade should not ask the same
- questions again, unless the user has used dpkg
- --purge to remove the package's configuration. The
- answers to configuration questions should be stored in an
- appropriate place in
- If a package has a vitally important piece of
- information to pass to the user (such as "don't run me
- as I am, you must edit the following configuration files
- first or you risk your system emitting badly-formatted
- messages"), it should display this in the
-
+ The Debian install process allows the user to choose from
+ a number of common tasks which a Debian system can be used to
+ perform. Selecting a task with
- Any necessary prompting should almost always be confined
- to the
+ This set of packages is all available packages which have the + name of the selected task in the Task field of their + control file. The format of this field is a list of tasks, + separated by commas. +
+ ++ You should not tag any packages as belonging to a task + before this has been discussed on the + debian-devel mailing list and a consensus about + doing that has been reached. +
+ ++ For third parties (and historical reasons), tasksel also + supports constructing tasks based on task + packages. These are packages whose names begin with + task-. Task packages should not be included in the + Debian archive. +
+ The package installation scripts should avoid producing
+ output which it is unnecessary for the user to see and
+ should rely on
+ Errors which occur during the execution of an installation + script must be checked and the installation must not + continue after an error. +
+ ++ Note that in general applies to package + maintainer scripts, too. +
-
+ You should not use
+ All packages which supply an instance of a common command
+ name (or, in general, filename) should generally use
+
- In the source package's Standards-Version control
- field, you should specify the most recent version number
- of this policy document with which your package complied
- when it was last updated. The current version number is
- &version;.
+ Package maintainer scripts may prompt the user if
+ necessary. Prompting should be done by communicating
+ through a program, such as
- This information may be used to file bug reports
- automatically if your package becomes too much out of
- date.
+ The Debian Configuration management specification is included
+ in the
- 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.
+ Packages which use the Debian Configuration management + specification may contain an additional +
- 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.
+ It also means that an upgrade should not ask the same
+ questions again, unless the user has used
+ dpkg --purge to remove the package's configuration.
+ The answers to configuration questions should be stored in an
+ appropriate place in
+ If a package has a vitally important piece of
+ information to pass to the user (such as "don't run me
+ as I am, you must edit the following configuration files
+ first or you risk your system emitting badly-formatted
+ messages"), it should display this in the
+
- You should regularly, and especially if your package has
- become out of date, check for the newest Policy Manual
- available and update your package, if necessary. When your
- package complies with the new standards you should update the
- Standards-Version source package field and
- release it.
+ Source packages should specify the most recent version number + of this policy document with which your package complied + when it was last updated. +
+ ++ This information may be used to file bug reports + automatically if your package becomes too much out of date. +
+ ++ The version is specified in the Standards-Version + control field. + The format of the Standards-Version field is + described in . +
+ +
+ You should regularly, and especially if your package has
+ become out of date, check for the newest Policy Manual
+ available and update your package, if necessary. When your
+ package complies with the new standards you should update the
+ Standards-Version source package field and
+ release it.
- Source packages should specify which binary packages they - require to be installed or not to be installed in order to - build correctly. For example, if building a package - requires a certain compiler, then the compiler should be - specified as a build-time dependency. -
++ Source packages should specify which binary packages they + require to be installed or not to be installed in order to + build correctly. For example, if building a package + requires a certain compiler, then the compiler should be + specified as a build-time dependency. +
-
- It is not necessary to explicitly specify build-time
- relationships on a minimal set of packages that are always
- needed to compile, link and put in a Debian package a
- standard "Hello World!" program written in C or C++. The
- required packages are called build-essential, and
- an informational list can be found in
-
+ It is not necessary to explicitly specify build-time
+ relationships on a minimal set of packages that are always
+ needed to compile, link and put in a Debian package a
+ standard "Hello World!" program written in C or C++. The
+ required packages are called build-essential, and
+ an informational list can be found in
+
-
- When specifying the set of build-time dependencies, one
- should list only those packages explicitly required by the
- build. It is not necessary to list packages which are
- required merely because some other package in the list of
- build-time dependencies depends on them.
+ When specifying the set of build-time dependencies, one
+ should list only those packages explicitly required by the
+ build. It is not necessary to list packages which are
+ required merely because some other package in the list of
+ build-time dependencies depends on them.
- If build-time dependencies are specified, it must be
- possible to build the package and produce working binaries
- on a system with only essential and build-essential
- packages installed and also those required to satisfy the
- build-time relationships (including any implied
- relationships). In particular, this means that version
- clauses should be used rigorously in build-time
- relationships so that one cannot produce bad or
- inconsistently configured packages when the relationships
- are properly satisfied.
-
- explains the technical details.
-
- If changes to the source code are made that are not
- specific to the needs of the Debian system, they should be
- sent to the upstream authors in whatever form they prefer
- so as to be included in the upstream version of the
- package.
- If you need to configure the package differently for
- Debian or for Linux, and the upstream source doesn't
- provide a way to do so, you should add such configuration
- facilities (for example, a new
+ If build-time dependencies are specified, it must be + possible to build the package and produce working binaries + on a system with only essential and build-essential + packages installed and also those required to satisfy the + build-time relationships (including any implied + relationships). In particular, this means that version + clauses should be used rigorously in build-time + relationships so that one cannot produce bad or + inconsistently configured packages when the relationships + are properly satisfied. +
-
- You should make sure that the
- If you need to edit a
- You should document your changes and updates to the source
- package properly in the
+ If changes to the source code are made that are not + specific to the needs of the Debian system, they should be + sent to the upstream authors in whatever form they prefer + so as to be included in the upstream version of the + package. +
+
+ If you need to configure the package differently for
+ Debian or for Linux, and the upstream source doesn't
+ provide a way to do so, you should add such configuration
+ facilities (for example, a new
+ You should make sure that the
- When
+ If you need to edit a
- Every time you put more than one shell command (this - includes using a loop) in a makefile command you - must make sure that errors are trapped. For - simple compound commands, such as changing directory and - then running a program, using && rather - than semicolon as a command separator is sufficient. For - more complex commands including most loops and - conditionals you should include a separate set -e - command at the start of every makefile command that's - actually one of these miniature shell scripts.
+ Changes in the Debian version of the package should be
+ briefly explained in the Debian changelog file
+
- The include file <varargs.h> is - provided to support end-users compiling very old software; - the library libtermcap is provided to support the - execution of software which has been linked against it - (either old programs or those such as Netscape which are - only available in binary form).
++ Mistakes in changelogs are usually best rectified by making + a new changelog entry rather than "rewriting history" by + editing old changelog entries. +
-- Debian packages should be patched to use - <stdarg.h> and ncurses - instead. -
-
+ The format of the
+ That format is a series of entries like this: -
- Many of the tools in the package management suite manipulate
- data represented in a common format, known as control
- data. The data is often stored in control
- files. Binary and source packages have control files,
- and the
+ package and version are the source + package name and version number. +
- A control file consists of one or more paragraphs of fields.
- The paragraphs are separated by blank lines. Some control
- files allow only one paragraph; others allow several, in
- which case each paragraph usually refers to a different
- package. (For example, in source packages, the first
- paragraph refers to the source package, and later paragraphs
- refer to binary packages generated from the source.)
+ distribution(s) lists the distributions where
+ this version should be installed when it is uploaded - it
+ is copied to the Distribution field in the
+
- Each paragraph consists of a series of data fields; each
- field consists of the field name, followed by a colon and
- then the data/value associated with that field. It ends at
- the end of the line. Horizontal whitespace (spaces and
- tabs) may occur immediately before or after the value and is
- ignored there; it is conventional to put a single space
- after the colon. For example, a field might be:
-
- Some fields' values may span several lines; in this case - each continuation line must start with a space or - tab. Any trailing spaces or tabs at the end of individual - lines of a field value are ignored. + The change details may in fact be any series of lines + starting with at least two spaces, but conventionally each + change starts with an asterisk and a separating space and + continuation lines are indented so as to bring them in + line with the start of the text above. Blank lines may be + used here to separate groups of changes, if desired.
- Except where otherwise stated only a single line of data is
- allowed and whitespace is not significant in a field body.
- Whitespace must not appear inside names (of packages,
- architectures, files or anything else) or version numbers,
- or between the characters of multi-character version
- relationships.
+ If this upload resolves bugs recorded in the Bug Tracking
+ System (BTS), they may be automatically closed on the
+ inclusion of this package into the Debian archive by
+ including the string: closes: Bug#nnnnn
+ in the change details.
- Field names are not case-sensitive, but it is usual to - capitalize the field names using mixed case as shown below. + The maintainer name and email address used in the changelog + should be the details of the person uploading this + version. They are not necessarily those of the + usual package maintainer. The information here will be + copied to the Changed-By field in the + .changes file (see ), + and then later used to send an acknowledgement when the + upload has been installed.
- Blank lines, or lines consisting only of spaces and tabs,
- are not allowed within field values or between fields - that
- would mean a new paragraph.
+ The date should be in RFC822 format
- This list here is not supposed to be exhaustive. Most fields - are dealt with elsewhere in this document. + The first "title" line with the package name should start + at the left hand margin; the "trailer" line with the + maintainer and date details should be preceded by exactly + one space. The maintainer details and the date must be + separated by exactly two spaces.
-- The name of the binary package. Package names consist 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. The use of lowercase - package names is required unless the package you're - building (or referring to, in other fields) is already - using uppercase characters.
-- This lists the source or binary package's version number - - see . -
-+ For more information on placement of the changelog files + within binary packages, please see . +
-
- The most recent version of the standards (the policy
- manual and associated texts) with which the package
- complies. This is updated manually when editing the
- source package to conform to newer standards; it can
- sometimes be used to tell when a package needs attention.
- Its format is described above; see
- .
+ In non-experimental packages you must use a format for
+
- In a
- Every package has a version number recorded in its - Version control file field. -
- -- The package management system imposes an ordering on version - numbers, so that it can tell whether packages are being up- or - downgraded and so that package system front end applications - can tell whether a package it finds available is newer than - the one installed on the system. The version number format - has the most significant parts (as far as comparison is - concerned) at the beginning. -
- -- The version number format is: - [epoch:]upstream_version[-debian_revision] -
- -
- The three components here are:
-
- This is a single (generally small) unsigned integer. It
- may be omitted, in which case zero is assumed. If it is
- omitted then the upstream_version may not
- contain any colons.
-
- It is provided to allow mistakes in the version numbers
- of older versions of a package, and also a package's
- previous version numbering schemes, to be left behind.
-
- This is the main part of the version number. It is
- usually the version number of the original ("upstream")
- package from which the
- The comparison behavior of the package management system
- with respect to the upstream_version is
- described below. The upstream_version
- portion of the version number is mandatory.
-
- The upstream_version may contain only
- alphanumerics
- This part of the version number specifies the version of
- the Debian package based on the upstream version. It
- may contain only alphanumerics and the characters
- + and . (plus and full stop) and is
- compared in the same way as the
- upstream_version is.
-
- It is optional; if it isn't present then the
- upstream_version may not contain a hyphen.
- This format represents the case where a piece of
- software was written specifically to be turned into a
- Debian package, and so there is only one "debianization"
- of it and therefore no revision indication is required.
-
- It is conventional to restart the
- debian_revision at 1 each time the
- upstream_version is increased.
-
- The package management system will break the version
- number apart at the last hyphen in the string (if there
- is one) to determine the upstream_version and
- debian_revision. The absence of a
- debian_revision compares earlier than the
- presence of one (but note that the
- debian_revision is the least significant part
- of the version number).
-
- The upstream_version and debian_revision - parts are compared by the package management system using the - same algorithm: -
- -- The strings are compared from left to right. -
- -- 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. -
- -- 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 allow us to leave behind - mistakes in version numbering, and to cope with situations - where the version numbering scheme changes. It is - 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). -
- -- If an upstream package has problematic version numbers they - should be converted to a sane form for use in the - Version field. -
-- In general, Debian packages should use the same version - numbers as the upstream sources.
+- However, in some cases where the upstream version number is - based on a date (e.g., a development "snapshot" release) the - package management system cannot handle these version - numbers without epochs. For example, dpkg will consider - "96May01" to be greater than "96Dec24".
- -- To prevent having to use epochs for every new upstream - version, the version number should be changed to the - following format in such cases: "19960501", "19961224". It - is up to the maintainer whether he/she wants to bother the - upstream maintainer to change the version numbers upstream, - too.
- -- Note that other version formats based on dates which are - parsed correctly by the package management system should - not be changed.
+ When- Native Debian packages (i.e., packages which have been - written especially for Debian) whose version numbers include - dates should always use the "YYYYMMDD" format.
+ Every time you put more than one shell command (this + includes using a loop) in a makefile command you + must make sure that errors are trapped. For + simple compound commands, such as changing directory and + then running a program, using && rather + than semicolon as a command separator is sufficient. For + more complex commands including most loops and + conditionals you should include a separate set -e + command at the start of every makefile command that's + actually one of these miniature shell scripts. +Maintainers should preserve the modification times of the upstream source files in a package, as far as is reasonably @@ -1850,17 +1710,39 @@ Package: libc6
- This file must be an executable makefile, and contains the - package-specific recipes for compiling the package and - building binary package(s) from the source. -
+
- It must start with the line #!/usr/bin/make -f,
+ The source package may not contain any hard links
+ This is not currently detected when building source
+ packages, but only when extracting
+ them.
+
+ Hard links may be permitted at some point in the
+ future, but would require a fair amount of
+ work.
+
+ This file must be an executable makefile, and contains the + package-specific recipes for compiling the package and + building binary package(s) from the source. +
+ +
+ It must start with the line #!/usr/bin/make -f,
so that it can be invoked by saying its name rather than
invoking
- The required and optional targets are as follows:
+ The targets are as follows (required unless stated otherwise):
- The build target should perform all
- non-interactive configuration and compilation of the
- package. If a package has an interactive pre-build
+ The build target should perform all the
+ configuration and compilation of the package.
+ If a package has an interactive pre-build
configuration routine, the Debianized source package
must either be built after this has taken place (so
that the binary package can be built without rerunning
@@ -1946,6 +1827,46 @@ Package: libc6
+ 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
+ (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.
+
+ If one or both of the targets build-arch and
+ build-indep are not provided, then invoking
+
+ The build-arch and build-indep targets
+ must not do anything that might require root privilege.
+
The binary target must be all that is
necessary for the user to build the binary package(s)
- produced from this source package. All of these
- targets are required to be non-interactive. It is
+ produced from this source package. It is
split into two parts:
@@ -2110,149 +2030,9 @@ Package: libc6
- This file records the changes to the Debian-specific parts of the
- package
- It has a special format which allows the package building - tools to discover which version of the package is being - built and find out other release-specific information. -
- -
- That format is a series of entries like this:
- [optional blank line(s), stripped] [blank line(s), included in output of dpkg-parsechangelog] [optional blank line(s), stripped]
- package and version are the source - package name and version number. -
- -
- distribution(s) lists the distributions where
- this version should be installed when it is uploaded - it
- is copied to the Distribution field in the
-
- urgency is the value for the Urgency
- field in the
- The change details may in fact be any series of lines - starting with at least two spaces, but conventionally each - change starts with an asterisk and a separating space and - continuation lines are indented so as to bring them in - line with the start of the text above. Blank lines may be - used here to separate groups of changes, if desired. -
- -
- If this upload resolves bugs recorded in the Bug Tracking
- System (BTS), they may be automatically closed on the
- inclusion of this package into the Debian archive by
- including the string: closes: Bug#nnnnn
- in the change details.
- The maintainer name and email address used in the changelog - should be the details of the person uploading this - version. They are not necessarily those of the - usual package maintainer. The information here will be - copied to the Changed-By field in the - .changes file, and then later used to send an - acknowledgement when the upload has been installed. -
- -
- The date should be in RFC822 format
- The first "title" line with the package name should start - at the left hand margin; the "trailer" line with the - maintainer and date details should be preceded by exactly - one space. The maintainer details and the date must be - separated by exactly two spaces. -
- -- It is possible to use a different format to the standard - one, by providing a parser for the format you wish to - use. -
-- A changelog parser must not interact with the user at - all. -
-
When
This file is not a permanent part of the source tree; it
@@ -2323,104 +2103,643 @@ Package: libc6
the file to the list in
+ The package management system manipulates data represented in
+ a common format, known as control data, stored in
+ control files.
+ Control files are used for source packages, binary packages and
+ the
- The source package may not contain any hard links
- This is not currently detected when building source
- packages, but only when extracting
- them.
-
- Hard links may be permitted at some point in the
- future, but would require a fair amount of
- work.
-
+ Each paragraph consists of a series of data fields; each
+ field consists of the field name, followed by a colon and
+ then the data/value associated with that field. It ends at
+ the end of the line. Horizontal whitespace (spaces and
+ tabs) may occur immediately before or after the value and is
+ ignored there; it is conventional to put a single space
+ after the colon. For example, a field might be:
+
- The "Description" control file field consists of two parts, - the synopsis or the short description, and the long description. - The field's format is as follows: + Some fields' values may span several lines; in this case + each continuation line must start with a space or a tab. + Any trailing spaces or tabs at the end of individual + lines of a field value are ignored.
-+ Except where otherwise stated, only a single line of data is + allowed and whitespace is not significant in a field body. + Whitespace must not appear inside names (of packages, + architectures, files or anything else) or version numbers, + or between the characters of multi-character version + relationships. +
- The description is intended to describe the program to a user - who has never met it before so that they know whether they - want to install it. It should also give information about the - significant dependencies and conflicts between this package - and others, so that the user knows why these dependencies and - conflicts have been declared. + Field names are not case-sensitive, but it is usual to + capitalize the field names using mixed case as shown below.
- Put important information first, both in the synopsis and - extended description. Sometimes only the first part of the - synopsis or of the description will be displayed. You can - assume that there will usually be a way to see the whole - extended description. + Blank lines, or lines consisting only of spaces and tabs, + are not allowed within field values or between fields - that + would mean a new paragraph.
-- The single line synopsis should be kept brief - certainly - under 80 characters. -
+- Do not include the package name in the synopsis line. The - display software knows how to display this already, and you - do not need to state it. Remember that in many situations - the user may only see the synopsis line - make it as - informative as you can. -
+
+ The
+ The first paragraph of the control file contains information about + the source package in general. The subsequent sets each describe a + binary package that the source tree builds. +
-+ The fields in the general paragraph (the first one, for the source + package) are: -
- Do not try to continue the single line synopsis into the - extended description. This will not work correctly when - the full description is displayed, and makes no sense - where only the summary (the single line synopsis) is - available. -
+- The extended description should describe what the package - does and how it relates to the rest of the system (in terms - of, for example, which subsystem it is which part of). -
++ The fields in the binary package paragraphs are: -
- The description field needs to make sense to anyone, even
- people who have no idea about any of the things the
- package deals with.
+
+
+ The syntax and semantics of the fields are described below. +
+ + + +
+ These fields are used by
+ The fields here may contain variable references - their
+ values will be substituted by
+ The
+ The fields in this file are:
+
+
+
+
+ This file contains a series of fields, identified and
+ separated just like the fields in the control file of
+ a binary package. The fields are listed below; their
+ syntax is described above, in .
+
+
+
+
+ The source package control file is generated by
+
+ The .changes files are used by the Debian archive maintenance + software to process updates to packages. They contain one + paragraph which contains information from the + debian/control file and other data about the + source package gathered via debian/changelog + and debian/rules. +
+ +
+ The fields in this file are:
+
+
+
+
+ This field identifies the source package name. +
+ +
+ In a main source control information, a
+ In the control file of a binary package it may be followed
+ by a version number in parentheses
+ The package maintainer's name and email address. The name + should come first, then the email address inside angle + brackets <> (in RFC822 format). +
+ ++ If the maintainer's name contains a full stop then the + whole field will not work directly as an email address due + to a misfeature in the syntax specified in RFC822; a + program using this field as an address must check for this + and correct the problem if necessary (for example by + putting the name in round brackets and moving it to the + end, and bringing the email address forward). +
++ 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. +
++ This field specifies an application area into which the package + has been classified. See . +
+ +
+ When it appears in the
+ By default,
+ This field represents how important that it is that the user + have the package installed. See . +
+ +
+ When it appears in the
+ By default,
+ The name of the binary package. +
+ ++ 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. +
++ This is the architecture string; it is a single word for + the Debian architecture. The special value all + indicates that the package is architecture-independent. +
+ +
+ In the main
+ In a
+ See for information how to get the + architecture for the build process. +
++ 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 main source control data 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. +
++ These fields describe the package's relationships with + other packages. Their syntax and semantics are described + in .
++ The most recent version of the standards (the policy + manual and associated texts) with which the package + complies. +
+ ++ 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 the all
+ four components may be specified.
+ The version number of a package. The format is: + [epoch:]upstream_version[-debian_revision] +
+ +
+ The three components here are:
+
+ This is a single (generally small) unsigned integer. It
+ may be omitted, in which case zero is assumed. If it is
+ omitted then the upstream_version may not
+ contain any colons.
+
+ It is provided to allow mistakes in the version numbers
+ of older versions of a package, and also a package's
+ previous version numbering schemes, to be left behind.
+
+ This is the main part of the version number. It is
+ usually the version number of the original ("upstream")
+ package from which the
+ The comparison behavior of the package management system
+ with respect to the upstream_version is
+ described below. The upstream_version
+ portion of the version number is mandatory.
+
+ The upstream_version may contain only
+ alphanumerics
+ This part of the version number specifies the version of
+ the Debian package based on the upstream version. It
+ may contain only alphanumerics and the characters
+ + and . (plus and full stop) and is
+ compared in the same way as the
+ upstream_version is.
+
+ It is optional; if it isn't present then the
+ upstream_version may not contain a hyphen.
+ This format represents the case where a piece of
+ software was written specifically to be turned into a
+ Debian package, and so there is only one "debianization"
+ of it and therefore no revision indication is required.
+
+ It is conventional to restart the
+ debian_revision at 1 each time the
+ upstream_version is increased.
+
+ The package management system will break the version
+ number apart at the last hyphen in the string (if there
+ is one) to determine the upstream_version and
+ debian_revision. The absence of a
+ debian_revision compares earlier than the
+ presence of one (but note that the
+ debian_revision is the least significant part
+ of the version number).
+
+ The upstream_version and debian_revision + parts are compared by the package management system using the + same algorithm: +
+ ++ The strings are compared from left to right. +
+ ++ 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. +
+ ++ 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 allow us to leave behind + mistakes in version numbering, and to cope with situations + where the version numbering scheme changes. It is + 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). +
++ 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. The field's format is as follows: +
+ +
+
The lines in the extended description can have these formats:
@@ -2448,7 +2767,7 @@ Package: libc6 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+ See for further information on this. +
+ +
+ 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".
+
+ This field includes the date the package was built or last edited. +
+ +
+ The value of this field is usually extracted from the
+
+ 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 + format value is the same as that of a package version + number except that no epoch or Debian revision is allowed + - see . +
+
+ This is a description of how important it is to upgrade to
+ this version from previous ones. It consists of a single
+ keyword usually taking one of the values low,
+ medium or high (not case-sensitive)
+ followed by an optional commentary (separated by a space)
+ which is usually in parentheses. For example:
+
+
+ The value of this field is usually extracted from the
+
+ This field contains the human-readable changes data, describing + the differences between the last version and the current one. +
+ ++ 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 + consiting only of a space and a full stop. +
+ +
+ The value of this field is usually extracted from the
+
+ Each version's change information should be preceded by a + "title" line giving at least the version, distribution(s) + and urgency, in a human-readable way. +
+ ++ If data from several versions is being returned the entry + 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). +
++ This field is a list of binary packages. +
+ +
+ 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. +
++ This 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. +
+ +
+ In the
+ In the
+ The special value byhand for the section in a + .changes file indicates that the file in question + is not an ordinary package file and must by installed by + hand by the distribution maintainers. If the section is + byhand the priority should be -. +
+ +
+ If a new Debian revision of a package is being shipped and
+ no new original source archive is being distributed the
+ .dsc must still contain the Files field
+ entry for the original source archive
+
+ A space-separated list of bug report numbers that the upload + governed by the .changes file closes. +
+ Additional user-defined fields may be added to the + source package control file. Such fields will be + ignored, and not copied to (for example) binary or + source package control files or upload control files. +
+ ++ If you wish to add additional unsupported fields to + these output files you should use the mechanism + described here. +
+ ++ Fields in the main source control information file with + names starting X, followed by one or more of + the letters BCS and a hyphen -, will + be copied to the output files. Only the part of the + field name after the hyphen will be used in the output + file. Where the letter B is used the field + will appear in binary package control files, where the + letter S is used in source package control + files and where C is used in upload control + (.changes) files. +
+ +
+ For example, if the main source information control file
+ contains the field
+
It is possible to supply scripts as part of a package which @@ -2539,7 +3200,7 @@ Package: libc6 considerations really apply to all shell scripts.
@@ -2561,7 +3222,7 @@ Package: libc6
@@ -2811,7 +3472,7 @@ Package: libc6
- It is an error for a package to contains files which
+ It is an error for a package to contain files which
are on the system in another package, unless
Replaces is used (see ).
-
-
- When
- This file is usually generated and modified dynamically by
-
- See
- This file is not a permanent part of the source tree; it
- is used while building packages to record which files are
- being generated.
- It should not exist in a shipped source package, and so it
- (and any backup files or temporary files such as
-
-
- If a package upload includes files besides the source
- package and any binary packages whose control files were
- made with
- This is the canonical temporary location for the
- construction of binary packages by the binary
- target. The directory
- If several binary packages are generated from the same
- source tree it is usual to use several
-
- Whatever
- As it exists on the FTP site, a Debian source package - consists of three related files. You must have the right - versions of all three to be able to use them. -
- -
-
- This file contains a series of fields, identified and
- separated just like the fields in the control file of
- a binary package. The fields are listed below; their
- syntax is described above, in .
-
-
-
- The source package control file is generated by
-
- This is a compressed (with gzip -9)
-
- This is a unified context diff (diff -u)
- giving the changes which are required to turn the
- original source into the Debian source. These changes
- may only include editing and creating plain files.
- The permissions of files, the targets of symbolic
- links and the characteristics of special files or
- pipes may not be changed and no files may be removed
- or renamed.
-
- All the directories in the diff must exist, except the
-
- The
-
-
-
- If there is no original source code - for example, if the
- package is specially prepared for Debian or the Debian
- maintainer is the same as the upstream maintainer - the
- format is slightly different: then there is no diff, and the
- tarfile is named
-
- dpkg-source -x is the recommended way to unpack a
- Debian source package. However, if it is not available it
- is possible to unpack a Debian source archive as follows:
-
- Untar the tarfile, which will create a Rename the
- Create the subdirectory Apply the diff using patch -p0. Untar the tarfile again if you want a copy of the original
- source code alongside the Debianised version.
- It is not possible to generate a valid Debian source archive
- without using
- The source package may not contain any hard links
-
- The source packaging tools manage the changes between the
- original and Debianised source using Adding or removing symbolic links, sockets or pipes. Changing the targets of symbolic links. Creating directories, other than Changes to the contents of binary files.
- Removing files, directories or symlinks.
-
- Changed text files which are missing the usual final
- newline (either in the original or the modified
- source tree).
- Changing the permissions of files (other than
-
-
Changes which cause
-
- Changes which are not represented, but which are not detected by
-
-
-
- The
- Many of the tools in the
- A file consists of one or more paragraphs of fields. The - paragraphs are separated by blank lines. Some control files - only allow one paragraph; others allow several, in which - case each paragraph often refers to a different package. -
- -- Each paragraph is a series of fields and values; each field - consists of a name, followed by a colon and the value. It - ends at the end of the line. Horizontal whitespace (spaces - and tabs) may occur before or after the value and is ignored - there; it is conventional to put a single space after the - colon. -
- -- Some fields' values may span several lines; in this case - each continuation line must start with a space or - tab. Any trailing spaces or tabs at the end of individual - lines of a field value are ignored. -
- -- Except where otherwise stated only a single line of data is - allowed and whitespace is not significant in a field body. - Whitespace may never appear inside names (of packages, - architectures, files or anything else), version numbers or - in between the characters of multi-character version - relationships. -
- -- Field names are not case-sensitive, but it is usual to - capitalise the field names using mixed case as shown below. -
- -- Blank lines, or lines consisting only of spaces and tabs, - are not allowed within field values or between fields - that - would mean a new paragraph. -
- -
- It is important to note that there are several fields which
- are optional as far as
- The name of the binary package. Package names consist of
- the alphanumerics and + - .
- (plus, minus and full stop).
-
- They must be at least two characters and must start with
- an alphanumeric. In current versions of dpkg they are
- sort of case-sensitive
- This lists the source or binary package's version number - - see . -
- -- This is the architecture string; it is a single word for - the Debian architecture. -
- -
-
- The special value all indicates that the package - is architecture-independent. -
- -
- In the main
- In a
- See for information how to get the - architecture for the build process. -
-- The package maintainer's name and email address. The name - should come first, then the email address inside angle - brackets <> (in RFC822 format). -
- -- If the maintainer's name contains a full stop then the - whole field will not work directly as an email address due - to a misfeature in the syntax specified in RFC822; a - program using this field as an address must check for this - and correct the problem if necessary (for example by - putting the name in round brackets and moving it to the - end, and bringing the email address forward). -
- -
- In a
- This field is usually optional in as far as the
-
- This field identifies the source package name. -
- -
- In a main source control information or a
-
- In the control file of a binary package (or in a
-
- These fields describe the package's relationships with - other packages. Their syntax and semantics are described - in .
-- In a binary package Packages file or main source - control file this field contains a description of the - binary package, in a special format. See for details. -
- -
- In a
- This is a boolean field which may occur only in the
- control file of a binary package (or in the
-
- If set to yes then
- These two fields classify the package. The - Priority represents how important that it is that - the user have it installed; the Section - represents an application area into which the package has - been classified. -
- -
- When they appear in the
- The section and priority are represented, though not as
- separate fields, in the information for each file in the
-
- These fields are not used by by
- These fields can appear in binary package control files,
- in which case they provide a default value in case the
-
- This field is a list of binary packages. -
- -
- 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.
-- This 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. -
- -
- In the
- In the
- The special value byhand for the section in a - .changes file indicates that the file in question - is not an ordinary package file and must by installed by - hand by the distribution maintainers. If the section is - byhand the priority should be -. -
- -
- If a new Debian revision of a package is being shipped and
- no new original source archive is being distributed the
- .dsc must still contain the Files field
- entry for the original source archive
-
+ This is the canonical temporary location for the
+ construction of binary packages by the binary
+ target. The directory
- The most recent version of the standards (the Debian Policy
- and associated texts) with which the package complies. This
- is updated manually when editing the source package to
- conform to newer standards; it can sometimes be used to
- tell when a package needs attention.
+ If several binary packages are generated from the same
+ source tree it is usual to use several
+
- Its format is the same as that of a version number except - that no epoch or Debian revision is allowed - see .
-
- In a
+ As it exists on the FTP site, a Debian source package + consists of three related files. You must have the right + versions of all three to be able to use them. +
-- Current distribution values are: +
- This is the current "released" version of Debian
- GNU/Linux. A new version is released approximately
- every 3 months after the development code has
- been frozen for a month of testing. Once the
- distribution is stable only major bug fixes
- are allowed. When changes are made to this
- distribution, the release number is increased
- (for example: 1.2r1 becomes 1.2r2 then 1.2r3, etc).
-
- This distribution value refers to the
- developmental part of the Debian distribution
- tree. New packages, new upstream versions of packages
- and bug fixes go into the unstable directory
- tree. Download from this distribution at your own
- risk.
- The packages with this distribution value do not meet - the criteria for inclusion in the main Debian - distribution as defined by the Policy Manual, but meet - the criteria for the contrib - Distribution. There is currently no distinction - between stable and unstable packages in the - contrib or non-free - distributions. Use your best judgement in downloading - from this Distribution.
-- Like the packages in the contrib seciton, - the packages in non-free do not meet the - criteria for inclusion in the main Debian distribution - as defined by the Policy Manual. Again, use your best - judgement in downloading from this Distribution.
+ All the directories in the diff must exist, except the +- The packages with this distribution value are deemed - by their maintainers to be high risk. Oftentimes they - represent early beta or developmental packages from - various sources that the maintainers want people to - try, but are not ready to be a part of the other parts - of the Debian distribution tree. Download at your own - risk.
-
+ If there is no original source code - for example, if the
+ package is specially prepared for Debian or the Debian
+ maintainer is the same as the upstream maintainer - the
+ format is slightly different: then there is no diff, and the
+ tarfile is named
+
+ dpkg-source -x is the recommended way to unpack a
+ Debian source package. However, if it is not available it
+ is possible to unpack a Debian source archive as follows:
+
+ Untar the tarfile, which will create a Rename the
- From time to time, (currently, every 3 months) the
- unstable distribution enters a state of
- "code-freeze" in anticipation of release as a
- stable version. During this period of testing
- (usually 4 weeks) only fixes for existing or
- newly-discovered bugs will be allowed.
-
+ Create the subdirectory
Apply the diff using patch -p0.
+Untar the tarfile again if you want a copy of the original + source code alongside the Debianised version.
+
+ It is not possible to generate a valid Debian source archive
+ without using
- This is a description of how important it is to upgrade to
- this version from previous ones. It consists of a single
- keyword usually taking one of the values LOW,
- MEDIUM or HIGH) followed by an optional
- commentary (separated by a space) which is usually in
- parentheses. For example:
-
- This field appears in the Adding or removing symbolic links, sockets or pipes. Changing the targets of symbolic links. Creating directories, other than Changes to the contents of binary files.
+ Removing files, directories or symlinks.
+
+ Changed text files which are missing the usual final
+ newline (either in the original or the modified
+ source tree).
+ Changing the permissions of files (other than
+
+
Changes which cause
+
+ Changes which are not represented, but which are not detected by
+
+
- Urgency keywords are not case-sensitive.
+ The- In .changes files and parsed changelogs, this - gives the date the package was built or last edited.
-
+ Many of the tools in the
- This field occurs in
+ See . +
-
- In a
+ It is important to note that there are several fields which
+ are optional as far as
- 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 - consiting only of a space and a full stop. -
+- Each version's change information should be preceded by a - "title" line giving at least the version, distribution(s) - and urgency, in a human-readable way. -
++ See . +
-- If data from several versions is being returned the entry - 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).
- ++ This section now contains only the fields that didn't belong + to the Policy manual. +