-
- 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.
@@ -6962,6 +6944,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 +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
+ 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 +8273,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.
+
+
+
+