Seconded, as amended in the 2000-12-22 debian-policy message with the header Message-ID: <[EMAIL PROTECTED]>
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
