-
- 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.
- The intent of this split is so that binary-only builds
- need not install the dependencies required for
- the build-indep target. However, this is not
- yet used in practice since dpkg-buildpackage
- -B, and therefore the autobuilders,
- invoke build rather than build-arch
- due to the difficulties in determining whether the
- optional build-arch target exists.
+ This split allows binary-only builds to not install the
+ dependencies required for the build-indep
+ target and skip any resource-intensive build tasks that
+ are only required when building architecture-independent
+ binary packages.
-
- If one or both of the targets build-arch and
- build-indep are not provided, then invoking
- debian/rules with one of the not-provided
- targets as arguments should produce a exit status code
- of 2. Usually this is provided automatically by make
- if the target is missing.
-
-
The build-arch and build-indep targets
must not do anything that might require root privilege.
@@ -2667,7 +2649,6 @@ Package: libc6
- Source (mandatory)
- Maintainer (mandatory)
- Uploaders
- - DM-Upload-Allowed
- Section (recommended)
- Priority (recommended)
- Build-Depends et al
@@ -2766,13 +2747,12 @@ Package: libc6
- Version (mandatory)
- Maintainer (mandatory)
- Uploaders
- - DM-Upload-Allowed
- Homepage
- Vcs-Browser, Vcs-Git, et al.
- Standards-Version (recommended)
- Build-Depends et al
- Checksums-Sha1
- and Checksums-Sha256 (recommended)
+ and Checksums-Sha256 (mandatory)
+
DM-Upload-Allowed
- Indicates that Debian Maintainers may upload this package to
- the Debian archive. The only valid value is yes. If
- the field DM-Upload-Allowed: yes is present in the
- source section of the source control file of the most recent
- version of a package in unstable or experimental, the Debian
- archive will accept uploads of this package signed with a key
- in the Debian Maintainer keyring. See the General
- Resolution for more
- details.
+ Obsolete, see below.
@@ -3876,6 +3847,28 @@ Checksums-Sha256:
+
+ Obsolete fields
+
+
+ The following fields have been obsoleted and may be found in packages
+ conforming with previous versions of the Policy.
+
+
+
+ DM-Upload-Allowed
+
+
+ Indicates that Debian Maintainers may upload this package to
+ the Debian archive. The only valid value is yes. This
+ field was used to regulate uploads by Debian Maintainers, See the
+ General Resolution for more details.
+
+
+
+
+
@@ -6016,7 +6009,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
- shlibs files also only support a limited range of
+ shlibs files also only support a limited range of
library SONAMEs, making it difficult to use shlibs
files in some unusual corner cases.
A shlibs file represents an SONAME as a library
@@ -6641,7 +6634,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
The shlibs system
- The shlibs system is an simpler alternative to
+ The shlibs system is a simpler alternative to
the symbols system for declaring dependencies for
shared libraries. It may be more appropriate for C++
libraries and other cases where tracking individual symbols is
@@ -6796,10 +6789,10 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
In our example, if the last change to the zlib1g
package that could change behavior for a client of that
- library was in version 1:1.2.3.3.dfsg-2, then
+ library was in version 1:1.2.3.3.dfsg-1, then
the shlibs entry for this library could say:
- libz 1 zlib1g (>= 1:1.2.3.3.dfsg-2~)
+ libz 1 zlib1g (>= 1:1.2.3.3.dfsg)
This version restriction must be new enough that any binary
built against the current version of the library will work
@@ -6811,7 +6804,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
As zlib1g also provides a udeb containing the shared
library, there would also be a second line:
- udeb: libz 1 zlib1g-udeb (>= 1:1.2.3.3.dfsg-2~)
+ udeb: libz 1 zlib1g-udeb (>= 1:1.2.3.3.dfsg)
@@ -6962,6 +6955,12 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
in /run should be stored on a temporary
file system.
+
+ Packages must not assume the /run
+ directory exists or is usable without a dependency
+ on initscripts (>= 2.88dsf-13.3) until the
+ stable release of Debian supports /run.
+
-
@@ -8050,33 +8049,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
+ format (RFC 1524) in the directory
+ /usr/lib/mime/packages/. The file name should be the
+ binary package's name.
The mime-support package provides the
- update-mime program which allows packages to
- register programs that can show, compose, edit or print
- MIME types.
-
-
-
- Packages containing such programs must register them
- with update-mime as documented in . They should not depend
- on, recommend, or suggest mime-support. Instead,
- they should just put something like the following in the
- postinst and postrm scripts:
-
-
- if [ -x /usr/sbin/update-mime ]; then
- update-mime
- fi
-
+ update-mime program, which integrates these
+ registrations in the /etc/mailcap file, using dpkg
+ triggers
+ Creating, modifying or removing a file in
+ /usr/lib/mime/packages/ using maintainer scripts will
+ not activate the trigger. In that case, it can be done by calling
+ dpkg-trigger --no-await /usr/lib/mime/packages from
+ the maintainer script after creating, modifying, or removing
+ the file.
+ .
+ Packages using this facility should not depend on,
+ recommend, or suggest mime-support.
-
@@ -8290,6 +8284,74 @@ exec /usr/lib/foo/foo "$@"
+
+ Alternate init systems
+
+ A number of other init systems are available now in Debian that
+ can be used in place of sysvinit. Alternative
+ init implementations must support running SysV init scripts as
+ described at [ for compatibility.
+ ]
+
+ 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
+ sysvinit by providing a SysV-style init script
+ with the same name as and equivalent functionality to any
+ init-specific job, as this is the only start-up configuration
+ method guaranteed to be supported by all init implementations. An
+ exception to this rule is scripts or jobs provided by the init
+ implementation itself; such jobs may be required for an
+ implementation-specific equivalent of the /etc/rcS.d/
+ scripts and may not have a one-to-one correspondence with the init
+ scripts.
+
+
+ Event-based boot with upstart
+
+
+ Packages may integrate with the upstart event-based
+ boot system by installing job files in the
+ /etc/init directory. SysV init scripts for which
+ an equivalent upstart job is available must query the output of
+ the command initctl version for the string
+ upstart and avoid running in favor of the native
+ upstart job, using a test such as this:
+
+if [ "$1" = start ] && which initctl >/dev/null && initctl version | grep -q upstart
+then
+ exit 1
+fi
+
+
+
+ Because packages shipping upstart jobs may be installed on
+ systems that are not using upstart, maintainer scripts must
+ still use the common update-rc.d and
+ invoke-rc.d interfaces for configuring runlevels
+ and for starting and stopping services. These maintainer
+ scripts must not call the upstart start,
+ restart, reload, or stop
+ interfaces directly. Instead, implementations of
+ invoke-rc.d must detect when upstart is running and
+ when an upstart job with the same name as an init script is
+ present, and perform the requested action using the upstart job
+ instead of the init script.
+
+
+ Dependency-based boot managers for SysV init scripts, such as
+ startpar, may avoid running a given init script
+ entirely when an equivalent upstart job is present, to avoid
+ unnecessary forking of no-op init scripts. In this case, the
+ boot manager should integrate with upstart to detect when the
+ upstart job in question is started or stopped to know when the
+ dependency has been satisfied.
+
+
+
+