X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=policy.sgml;h=b57dd76b40903db5c051f6386b4a99d1724b1762;hb=40c80fdec0cbed3bfd337d4a3b2c24ce2377d63a;hp=cca4b6d7bec1bcc0691a8b67629ba585aca8cf1e;hpb=6240129c6aea6033a60a39dbe0719b21ec3018ef;p=debian%2Fdebian-policy.git diff --git a/policy.sgml b/policy.sgml index cca4b6d..b57dd76 100644 --- a/policy.sgml +++ b/policy.sgml @@ -489,9 +489,9 @@ must not require or recommend a package outside of main for compilation or execution (thus, the - package must not declare a "Depends", "Recommends", or - "Build-Depends" relationship on a non-main - package), + package must not declare a "Pre-Depends", "Depends", + "Recommends", "Build-Depends", or "Build-Depends-Indep" + relationship on a non-main package), must not be so buggy that we refuse to support them, @@ -4629,7 +4629,7 @@ Depends: libc6 (>= 2.2.1), exim | mail-transport-agent Relationships may be restricted to a certain set of architectures. This is indicated in brackets after each individual package name and the optional version specification. - The brackets enclose a list of Debian architecture names + The brackets enclose a non-empty list of Debian architecture names in the format described in , separated by whitespace. Exclamation marks may be prepended to each of the names. (It is not permitted for some names to be @@ -5803,7 +5803,7 @@ Replaces: mail-transport-agent installed on the system, all of the libraries needed are also 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 linnked + 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 symbols file or a shlibs file, which provide information on the @@ -5996,16 +5996,7 @@ Replaces: mail-transport-agent libraries, put a call to dpkg-shlibdeps into your debian/rules file in the source package. List all of the compiled binaries, libraries, or loadable - modules in your package. If your source package builds only a - single binary package that contains only compiled binaries and - libraries (but no scripts) and is not multiarch, you can use a - command such as: - -dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \ - debian/tmp/usr/lib/* - - but normally finding all of the binaries is more - complex. + modules in your package. The easiest way to do this is to use a package helper framework such as debhelper. If you are using debhelper, the dh_shlibdeps @@ -6029,7 +6020,10 @@ dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \ binary package. Again, dh_shlibdeps and dh_gencontrol will handle all of this for - you if you're using debhelper. + you if you're using debhelper, including generating + separate substvars files for each binary + package and calling dpkg-gencontrol with the + appropriate flags.

@@ -6175,7 +6169,7 @@ libz.so.1 zlib1g #MINVER# following symbols file: libGL.so.1 libgl1 -| libgl1-mesa-glx #MINVER# + | libgl1-mesa-glx #MINVER# publicGlSymbol@Base 6.3-1 [...] implementationSpecificSymbol@Base 6.5.2-7 1 @@ -6216,7 +6210,8 @@ libGL.so.1 libgl1 * Build-Depends-Package: zlib1g-dev - (Don't forget the leading space.) + (Don't forget the space before the * so that it will + be parsed as part of the entry for that library.)

@@ -6403,12 +6398,10 @@ int library_do_operation(enum library_op); directory"

- When packages are being built, - any debian/shlibs files are copied into the - control information file area of the temporary build - directory and given the name shlibs. These - files give details of any shared libraries included in - the same package. + These files are generated as part of the package build + process and staged for inclusion as control files in the + binary packages being built. They provide details of + any shared libraries included in the same package.

@@ -6559,34 +6552,19 @@ udeb: libz 1 zlib1g-udeb (>= 1:1.2.3.3.dfsg-1) Providing a shlibs file

- If your package provides a shared library, you need to create - a shlibs file following the format described - above. It is usual to call this - file debian/shlibs (but if you have multiple - binary packages, you might want to call - it debian/package.shlibs instead). - Then let debian/rules install it in the control - information file area: - -install -m644 debian/shlibs debian/tmp/DEBIAN - - or, in the case of a multi-binary package: - -install -m644 debian/package.shlibs debian/package/DEBIAN/shlibs - - An alternative way of doing this is to create - the shlibs file in the control information file - area directly from debian/rules without using - a debian/shlibs file at all, + To provide a shlibs file for a shared library + binary package, create a shlibs file following + the format described above and place it in + the DEBIAN directory for that package during the + build. It will then be included as a control file for that + package This is what dh_makeshlibs in the debhelper suite does. If your package also has a udeb that provides a shared library, dh_makeshlibs can automatically generate the udeb: lines if you specify the name of the udeb with the --add-udeb option. - - since the debian/shlibs file itself is ignored by - dpkg-shlibdeps. + .

@@ -6697,6 +6675,25 @@ install -m644 debian/package.shlibs debian/package/DEBIAN/ symlinked there, is relaxed to a recommendation.

+ +

+ The additional directory /run in the root + file system is allowed. /run + replaces /var/run, and the + subdirectory /run/lock + replaces /var/lock, with + the /var directories replaced by symlinks + for backwards compatibility. /run + and /run/lock must follow all of the + requirements in the FHS for /var/run + and /var/lock, respectively, such as file + naming conventions, file format requirements, or the + requirement that files be cleared during the boot + process. Files and directories residing + in /run should be stored on a temporary + file system. +

+

The following directories in the root filesystem are @@ -6839,6 +6836,29 @@ rmdir /usr/local/share/emacs 2>/dev/null || true though the spool may still be physically located there.

+ + + /run and /run/lock + +

+ The directory /run is cleared at boot, normally + by being a mount point for a temporary file system. Packages + therefore must not assume that any files or directories + under /run other than /run/lock + exist unless the package has arranged to create those files or + directories since the last reboot. Normally, this is done by + the package via an init script. See + for more information. +

+ +

+ Packages must not include files or directories + under /run, or under the + older /var/run and /var/lock paths. + The latter paths will normally be symlinks or other + redirections to /run for backwards compatibility. +

+ @@ -7213,15 +7233,14 @@ test -f program-executed-later-in-script || exit 0

- /var/run and /var/lock may be mounted - as temporary filesystems - For example, using the RAMRUN and RAMLOCK - options in /etc/default/rcS. - , so the init.d scripts must handle this - correctly. This will typically amount to creating any required - subdirectories dynamically when the init.d script - is run, rather than including them in the package and relying on - dpkg to create them. + Files and directories under /run, including ones + referred to via the compatibility paths /var/run + and /var/lock, are normally stored on a temporary + filesystem and are normally not persistent across a reboot. + The init.d scripts must handle this correctly. + This will typically mean creating any required subdirectories + dynamically when the init.d script is run. + See for more information.

@@ -11697,7 +11716,7 @@ END-INFO-DIR-ENTRY dpkg-divert --package smailwrapper --remove --rename \ --divert /usr/sbin/smail.real /usr/sbin/smail fi - where 1.02-2 is the version at which the + where 1.0-2 is the version at which the diversion was first added to the package. The postrm should not remove the diversion on upgrades both because there's no reason to remove the diversion only to immediately re-add it and since the