X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=policy.sgml;h=43926534da730cac53b3f8dcd6ae16b0e9f1f441;hb=fadd5e8b67183327a7b3c0f9872396242e784875;hp=050c688438db4cb9e95731c6e71106debbd6584a;hpb=55b89aacf0291dd3fea8771d8bef75efb8e64b4d;p=debian%2Fdebian-policy.git diff --git a/policy.sgml b/policy.sgml index 050c688..4392653 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1988,51 +1988,33 @@ zope.

- build-arch (optional), - build-indep (optional) + build-arch (required), + build-indep (required)

- 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. @@ -6016,7 +5998,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 @@ -6796,10 +6778,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 +6793,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 +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. +

@@ -8290,6 +8278,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. +

+ + +