X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=policy.sgml;h=3a2e7e1599364c3c4d6b74f72136deabb22263ac;hb=a70d6da906aaaf53839b693f10c66a040c58da19;hp=fa1c39aca19f0e8e051179f648d35f0ebe1304d1;hpb=8fc92535f6ccb673d7afeae1353118151f5186c3;p=debian%2Fdebian-policy.git diff --git a/policy.sgml b/policy.sgml index fa1c39a..3a2e7e1 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. @@ -5646,7 +5628,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)

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 @@ -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 @@ -6238,9 +6220,9 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)

- 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: enum library_op { OP_FOO, OP_BAR }; int library_do_operation(enum library_op); @@ -6489,8 +6471,9 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) recent version of the shared library that changed the behavior of that symbol, whether by adding it, changing its function signature (the parameters, their types, or the - return type), or its behavior in a way that is visible to a - caller. id-of-dependency-template is an optional + return type), or changing its behavior in a way that is + visible to a caller. + id-of-dependency-template is an optional field that references an alternative-dependency-template; see below for a full description. @@ -6798,7 +6781,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) 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-1) + 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 @@ -6810,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-1) + udeb: libz 1 zlib1g-udeb (>= 1:1.2.3.3.dfsg)

@@ -6961,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. +

@@ -7877,6 +7866,74 @@ Reloading description configuration...done.

+ + 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. +

+ + + Cron jobs