Bug#80347: PROPOSED] allow/document use of Debian Configuration management system (debconf)
Seconded, as amended in the 2000-12-22 debian-policy message with the header
Message-ID: <[🔎] 20001222224556.A32414@kitenet.net>
Thanks,
--
Raul
On Fri, Dec 22, 2000 at 03:26:50PM -0800, Joey Hess wrote:
> 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
Reply to: