Package: debian-policy
Severity: wishlist
Rationale:
2.5% of debian packages[1] use debconf to prompt the user at install
time, and this number is growing daily. The benefits of using debconf are
briefly explained at http://kitenet.net/doc/debconf-doc/introduction.html;
they include preconfiguration, (mostly) noninteractive installation,
elimination of redundant prompting, consistency of user interface, etc.
I feel that with this increasing number of packages using debconf, plus
the existance of a nascent second implementation of the Debian
configuration management system (cdebconf), and the stabalization of the
protocol these things use, the time has finally come to reflect the use of
these things in policy.
Policy should document existing practice; existing practice is to use
debconf or manually ask questions, with the latter perhaps eventually
being phased out. So this proposal does not mandate the use of debconf,
it merely mentions and condones it.
This proposal also moves the spec defining the Debian configuration
management system into policy, as a supporting document like the menu
policy or mime policy. Or rather, it moves _most_ of it in.
Unfortunatly, part of the full spec[2] -- the whole database backend --
is proving difficult to implement, and no implementation exists. I don't
think dragging that into policy makes sense, before it is coded and in
use. So when the proposal talks about the "Debian Configuration management
specification", it is referring to an abridged version of that document.
I attach such an abridged version in docbook XML format, to this message
(as a tarball; there are several xml files and a text and html versions and
other cruft. The Makefile and other similar cruft is not considered part of
this proposal ;-).
Proposal:
--- tmp/policy.text Fri Dec 22 14:05:33 2000
+++ policy.text Fri Dec 22 14:05:24 2000
@@ -618,12 +618,47 @@
This means, amongst other things, using the `--quiet' option on
`install-info'.
+ Errors which occur during the execution of an installation script
+ should be checked and the installation should not continue after an
+ error.
+
+ Note, that Section 4.4, `Scripts', in general applies to package
+ maintainer scripts, too.
+
+ You should not use `dpkg-divert' on a file belonging to another
+ package without consulting the maintainer of that package first.
+
+ All packages which supply an instance of a common command name (or, in
+ general, filename) should generally use `update-alternatives', so that
+ they may be installed together. If `update-alternatives' is not used,
+ then each package must use `Conflicts' to ensure that other packages
+ are de-installed. (In this case, it may be appropriate to specify a
+ conflict against earlier versions of something that previously did not
+ use `update-alternatives' -- this is an exception to the usual rule
+ that this not allowed).
+
+2.3.9. Prompting in maintainer scripts
+--------------------------------------
+
+ Package maintainer scripts may prompt the user if necessary. Prompting
+ may be accomplished by hand, or by communicating with a program,
+ such as debconf, which conforms to the Debian Configuration management
+ specification, version 2 or higher. (As defined in the file
+ <some filename> in the debian-policy package.)
+
+ Packages which use the Debian Configuration management
+ specification may contain an additional `config' script and a
+ `templates' file in their control archive. The `config' script may
+ be run before the preinst, and before the package is unpacked or any of
+ its dependancies or pre-dependancies are satisfied, so it must work
+ using only the tools present in the base system.
+
Packages should try to minimize the amount of prompting they need to
do, and they should ensure that the user will only ever be asked each
question once. This means that packages should try to use appropriate
shared configuration files (such as `/etc/papersize' and
- `/etc/news/server'), rather than each prompting for their own list of
- required pieces of information.
+ `/etc/news/server'), and shared debconf variables rather than each
+ prompting for their own list of required pieces of information.
It also means that an upgrade should not ask the same questions again,
unless the user has used `dpkg --purge' to remove the package's
@@ -634,38 +669,19 @@
If a package has a vitally important piece of information to pass to
the user (such as "don't run me as I am, you must edit the following
configuration files first or you risk your system emitting
- badly-formatted messages"), it should display this in the `postinst'
- script and prompt the user to hit return to acknowledge the message.
- Copyright messages do not count as vitally important (they belong in
+ badly-formatted messages"), it should display this in the `config' or
+ `postinst' script and prompt the user to hit return to acknowledge the
+ message. Copyright messages do not count as vitally important (they belong in
`/usr/share/doc/<package>/copyright'); neither do instructions on how
to use a program (these should be in on line documentation, where all
the users can see them).
Any necessary prompting should almost always be confined to the
- post-installation script, and should be protected with a conditional
+ `config' script or the `postinst' script. If it is done in the
+ `postinst' it should be protected with a conditional
so that unnecessary prompting doesn't happen if a package's
installation fails and the `postinst' is called with `abort-upgrade',
`abort-remove' or `abort-deconfigure'.
-
- Errors which occur during the execution of an installation script
- should be checked and the installation should not continue after an
- error.
-
- Note, that Section 4.4, `Scripts', in general applies to package
- maintainer scripts, too.
-
- You should not use `dpkg-divert' on a file belonging to another
- package without consulting the maintainer of that package first.
-
- All packages which supply an instance of a common command name (or, in
- general, filename) should generally use `update-alternatives', so that
- they may be installed together. If `update-alternatives' is not used,
- then each package must use `Conflicts' to ensure that other packages
- are de-installed. (In this case, it may be appropriate to specify a
- conflict against earlier versions of something that previously did not
- use `update-alternatives' -- this is an exception to the usual rule
- that this not allowed).
-
--
see shy jo
[1] http://kitenet.net/programs/debconf/stats/
[2] http://kitenet.net/doc/debconf-doc/specification.html
Attachment:
spec.tar.gz
Description: Binary data