From: Manoj Srivastava Date: Thu, 16 Jun 2005 05:11:39 +0000 (+0000) Subject: * Corrections to chapter 6 X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=dc9aa8f85c22c5438c9608beb413c2977070b441;p=debian%2Fdebian-policy.git * Corrections to chapter 6 Author: jdg Date: 2001/04/23 20:39:14 * Corrections to chapter 6 git-archimport-id: srivasta@debian.org--etch/debian-policy--devel--3.0--patch-100 --- diff --git a/policy.sgml b/policy.sgml index 1f622ef..8db3804 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1181,9 +1181,8 @@ Source packages - + Standards conformance -

In the source package's Standards-Version control @@ -2243,7 +2242,7 @@ To be precise, the string should match the following Perl regular expression: -/closes:\s*(?:bug)?\#\s?\d+(?:,\s*(?:bug)?\#\s?\d+)*/i +/closes:\s*(?:bug)?\#\s?\d+(?:,\s*(?:bug)?\#\s?\d+)*/i Then all of the bug numbers listed will be closed by the archive maintenance script (katie), or in @@ -2491,10 +2490,10 @@

- These scripts should be the files preinst, + These scripts are the files preinst, postinst, prerm and postrm in the control area of the package. They must be proper executable - files; if they are scripts (which is recommended) they must + files; if they are scripts (which is recommended), they must start with the usual #! convention. They should be readable and executable by anyone, and not world-writable.

@@ -2511,22 +2510,12 @@ well.

-

- It is necessary for the error recovery procedures that the - scripts be idempotent: i.e., invoking the same script several - times in the same situation should do no harm. If the first - call failed, or aborted half way through for some reason, - the second call should merely do the things that were left - undone the first time, if any, and exit with a success - status. -

-

When a package is upgraded a combination of the scripts from - the old and new packages is called in amongst the other - steps of the upgrade procedure. If your scripts are going - to be at all complicated you need to be aware of this, and - may need to check the arguments to your scripts. + the old and new packages is called during the upgrade + procedure. If your scripts are going to be at all + complicated you need to be aware of this, and may need to + check the arguments to your scripts.

@@ -2537,39 +2526,47 @@ postrm afterwards.

-

Programs called from maintainer scripts should not - normally have a path prepended to them. Before installation - is started the package management system checks to see if - the programs ldconfig, +

+ Programs called from maintainer scripts should not normally + have a path prepended to them. Before installation is + started, the package management system checks to see if the + programs ldconfig, start-stop-daemon, install-info, and update-rc.d can be found via the PATH environment variable. Those programs, and any - other program that one would expect to on the PATH, - should thus be invoked without an absolute + other program that one would expect to be on the + PATH, should thus be invoked without an absolute pathname. Maintainer scripts should also not reset the - PATH, though they might choose to modify it by pre- - or appending package-specific directories. These + PATH, though they might choose to modify it by + prepending or appending package-specific directories. These considerations really apply to all shell scripts.

 + Maintainer scripts Idempotency

- It is very important to make maintainer scripts - idempotent. - + It is necessary for the error recovery procedures that the + scripts be idempotent. This means that if it is run + successfully, and then it is called again, it doesn't bomb + out or cause any harm, but just ensures that everything is + the way it ought to be. If the first call failed, or + aborted half way through for some reason, the second call + should merely do the things that were left undone the first + time, if any, and exit with a success status if everything + is OK. +

- That means that if it runs successfully or fails - and then you call it again it doesn't bomb out, - but just ensures that everything is the way it - ought to be. + This is so that if an error occurs, the user interrupts + dpkg or some other unforeseen circumstance + happens you don't leave the user with a badly-broken + package when dpkg attempts to repeat the + action.

- This is so that if an error occurs, the - user interrupts dpkg or some other - unforeseen circumstance happens you don't leave the - user with a badly-broken package. +

+ Controlling terminal for maintainer scripts @@ -2627,7 +2624,7 @@

old-postinst abort-upgrade - new version

+ new-version

conflictor's-postinst abort-remove @@ -2719,10 +2716,11 @@ The procedure on installation/upgrade/overwrite/disappear (i.e., when running dpkg --unpack, or the unpack stage of dpkg --install) is as follows. In each - case if an error occurs the actions are, in general, run - backwards - this means that the maintainer scripts are run - with different arguments in reverse order. These are the - `error unwind' calls listed below. + case, if a major error occurs (unless listed below) the + actions are, in general, run backwards - this means that the + maintainer scripts are run with different arguments in + reverse order. These are the `error unwind' calls listed + below. @@ -2813,7 +2811,7 @@ new-preinst install - Error unwind versions, respectively: + Error unwind actions, respectively: new-postrm abort-upgrade old-version new-postrm abort-install old-version @@ -2830,19 +2828,22 @@ The new package's files are unpacked, overwriting any that may be on the system already, for example any from the old version of the same package or from - another package (backups of the old files are left - around, and if anything goes wrong the package + another package. Backups of the old files are kept + temporarily, and if anything goes wrong the package management system will attempt to put them back as - part of the error unwind). + part of the error unwind.

It is an error for a package to contains files which are on the system in another package, unless Replaces is used (see ). - Currently the --force-overwrite flag is +

@@ -2857,7 +2858,7 @@

Packages which overwrite each other's files produce - behavior which though deterministic is hard for the + behavior which, though deterministic, is hard for the system administrator to understand. It can easily lead to `missing' programs if, for example, a package is installed which overwrites a file from another @@ -2871,7 +2872,7 @@

- A directory will never be replaced by a symbolic links + A directory will never be replaced by a symbolic link to a directory or vice versa; instead, the existing state (symlink or not) will be left alone and dpkg will follow the symlink if there is @@ -2925,7 +2926,7 @@

Any packages all of whose files have been overwritten during the installation, and which aren't required for dependencies, are considered to have been removed. - For each such package, + For each such package

dpkg calls: @@ -2972,12 +2973,17 @@

The new package's status is now sane, and recorded as - `unpacked'. Here is another point of no return - if - the conflicting package's removal fails we do not - unwind the rest of the installation; the conflicting - package is left in a half-removed limbo. + `unpacked'. +

+ +

+ Here is another point of no return - if the + conflicting package's removal fails we do not unwind + the rest of the installation; the conflicting package + is left in a half-removed limbo.

+

If there was a conflicting package we go and do the @@ -2997,7 +3003,7 @@

When we configure a package (this happens with dpkg --install, or with --configure), we first - update the conffiles and then call: + update any conffiles and then call: postinst configure most-recently-configured-version @@ -3031,7 +3037,7 @@

- The package's files are removed (except conffiles). + The package's files are removed (except conffiles).

@@ -3040,15 +3046,17 @@

-

All the maintainer scripts except the postrm are removed. +

+ All the maintainer scripts except the postrm + are removed.

If we aren't purging the package we stop here. Note - that packages which have no postrm and no conffiles - are automatically purged when removed, as there is no - difference except for the dpkg - status.

+ that packages which have no postrm and no + conffiles are automatically purged when + removed, as there is no difference except for the + dpkg status.

@@ -3066,7 +3074,8 @@ No attempt is made to unwind after errors during - removal.

+ removal. +