X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=policy.sgml;h=5760a3f6621cde4cf10492bad8cdafb1df9a49f4;hb=0fd03bb3692fc5a385bb332266bc5f41b34c75d5;hp=55200064a4ffe8250dceafd2099e7b0555cc3bad;hpb=0850327842e8acea3d3a959be46b020da177ba6e;p=debian%2Fdebian-policy.git diff --git a/policy.sgml b/policy.sgml index 5520006..5760a3f 100644 --- a/policy.sgml +++ b/policy.sgml @@ -714,21 +714,62 @@
The Debian archive maintainers provide the authoritative list of sections. At present, they are: - admin, cli-mono, comm, database, - devel, debug, doc, editors, - education, electronics, embedded, - fonts, games, gnome, graphics, - gnu-r, gnustep, hamradio, haskell, - httpd, interpreters, introspection, - java, kde, kernel, libs, - libdevel, lisp, localization, - mail, math, metapackages, misc, - net, news, ocaml, oldlibs, - otherosfs, perl, php, python, - ruby, science, shells, sound, - tex, text, utils, vcs, - video, web, x11, xfce, - zope. The additional section debian-installer +admin, +cli-mono, +comm, +database, +debug, +devel, +doc, +editors, +education, +electronics, +embedded, +fonts, +games, +gnome, +gnu-r, +gnustep, +graphics, +hamradio, +haskell, +httpd, +interpreters, +introspection, +java, +kde, +kernel, +libdevel, +libs, +lisp, +localization, +mail, +math, +metapackages, +misc, +net, +news, +ocaml, +oldlibs, +otherosfs, +perl, +php, +python, +ruby, +science, +shells, +sound, +tasks, +tex, +text, +utils, +vcs, +video, +web, +x11, +xfce, +zope. + The additional section debian-installer contains special packages used by the installer and is not used for normal Debian packages.
@@ -1947,51 +1988,33 @@ -- A package may also provide one or both of the targets - build-arch and build-indep. - The build-arch target, if provided, should + The build-arch target must 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 + target must 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). -
- -
- If build-arch or build-indep targets are
- provided in the rules file, the build target
+ The build target
should either depend on those targets or take the same
actions as invoking those targets would perform.
- 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.
@@ -2632,6 +2655,7 @@ Package: libc6
+ Debian source packages are increasingly developed using VCSs. The
+ purpose of the following fields is to indicate a publicly accessible
+ repository where the Debian source package is developed.
+
+
+ URL of a web interface for browsing the repository.
+
+ The field name identifies the VCS. The field's value uses the
+ version control system's conventional syntax for describing
+ repository locations and should be sufficient to locate the
+ repository used for packaging. Ideally, it also locates the
+ branch used for development of new versions of the Debian
+ package.
+
+ In the case of Git, the value consists of a URL, optionally
+ followed by the word -b and the name of a branch in
+ the indicated repository, following the syntax of the
+ git clone command. If no branch is specified, the
+ packaging should be on the default branch.
+
+ More than one different VCS may be specified for the same
+ package.
+
The relations allowed are <<, <=,
- =, >= and >> for
- strictly earlier, earlier or equal, exactly equal, later or
- equal and strictly later, respectively. The deprecated
- forms < and > were used to mean
- earlier/later or equal, rather than strictly earlier/later,
- so they should not appear in new packages (though
-
@@ -4678,7 +4752,8 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
- For binary relationship fields, the architecture restriction
+ For binary relationship fields and the Built-Using
+ field, the architecture restriction
syntax is only supported in the source package control
file
+ Some binary packages incorporate parts of other packages when built + but do not have to depend on those packages. Examples include + linking with static libraries or incorporating source code from + another package during the build. In this case, the source packages + of those other packages are a required part of the complete source + (the binary package is not reproducible without them). +
+ +
+ A Built-Using field must list the corresponding source
+ package for any such binary package incorporated during the build
+
+ A package using the source code from the gcc-4.6-source
+ binary package built from the gcc-4.6 source package would
+ have this field in its control file:
+
+ A package including binaries from grub2 and loadlin would
+ have this field in its control file:
+
To determine the soversion, look at
the SONAME of the library, stored in the
- ELF SONAME attribute. it is usually of the
+ ELF SONAME attribute. It is usually of the
form name.so.major-version (for
example, libz.so.1). The version part is the part
which comes after .so., so in that example it
@@ -5832,30 +5954,43 @@ Replaces: mail-transport-agent
installed. These dependencies must be added to the binary
package when it is built, since they may change based on which
version of a shared library the binary or library was linked
- with. To allow these dependencies to be constructed, shared
- libraries must provide either a
- These two mechanisms differ in the degree of detail that they
- provide. A
+ The two mechanisms differ in the degree of detail that they
+ provide. A
+ A
-
@@ -5875,9 +6017,10 @@ Replaces: mail-transport-agent
required by
- If your package contains any compiled binaries or shared
- libraries, put a call to
@@ -5928,25 +6070,26 @@ Replaces: mail-transport-agent
- This command puts the dependency information into
- the
There are two types of ABI changes: ones that are
backward-compatible and ones that are not. An ABI change is
- backward-compatible if any binary was linked with the previous
- version of the shared library will still work correctly with
- the new version of the shared library. Adding new symbols to
- the shared library is a backward-compatible change. Removing
- symbols from the shared library is not. Changing the behavior
- of a symbol may or may not be backward-compatible depending on
- the change; for example, changing a function to accept a new
- enum constant not previously used by the library is generally
+ backward-compatible if any reasonable program or library that
+ was linked with the previous version of the shared library
+ will still work correctly with the new version of the shared
+ library.
- A common example of when a change to the is required is a
- function that takes an enum or struct argument that controls
- what the function does. For example:
+ A common example of when a change to the dependency version
+ is required is a function that takes an enum or struct
+ argument that controls what the function does. For example:
@@ -6132,8 +6287,8 @@ Replaces: mail-transport-agent
During the package build, if the package itself
contains shared libraries with
@@ -6625,7 +6781,7 @@ Replaces: mail-transport-agent
library was in version 1:1.2.3.3.dfsg-1, then
the shlibs entry for this library could say:
+ Packages must not assume the
@@ -7876,33 +8038,28 @@ Reloading description configuration...done.
- Packages which provide the ability to view/show/play,
- compose, edit or print MIME types should register themselves
- as such following the current MIME support policy.
+ Packages which provide programs to view/show/play, compose, edit or
+ print MIME types should register them as such by placing a file in
+
The
- Packages containing such programs must register them
- with
+ A number of other init systems are available now in Debian that
+ can be used in place of
+ Packages may integrate with these replacement init systems by
+ providing implementation-specific configuration information about
+ how and when to start a service or in what order to run certain
+ tasks at boot time. However, any package integrating with other
+ init systems must also be backwards-compatible with
+
+ Packages may integrate with the
+ Because packages shipping upstart jobs may be installed on
+ systems that are not using upstart, maintainer scripts must
+ still use the common
+ Dependency-based boot managers for SysV init scripts, such as
+
+ All copyright files must be encoded in UTF-8. +
+
+ See