Hi! On Sat, 2013-03-02 at 18:45:30 +0900, Charles Plessy wrote: > Le Sun, Feb 24, 2013 at 04:41:55PM +0900, Charles Plessy a écrit : > > I am having a look at how to document triggers. In order to simplify the > > explanation and re-use more easily material from the file above, I think > > that we would benefit from documenting the dpkg states for a package.
This is documented in the dpkg man page (PACKAGE STATES), sorry for not mentioning this before. > How about adding the following to the Policy's section 6.1 (Introduction to > package maintainer scripts) ? We unified the states in policy to be all capitalized some time ago, I think it would make sense to follow that convention to not confuse the terminology usage. > Dpkg defines the folowing states for the packages. > <taglist> > <tag><tt>not-installed</tt></tag> > <item> > The package is not installed or has been purged. > </item> I'm not sure, if we should mention how to transition from/to states in this description, doing that in a dedicated section on how those transitions happen might be better (this re to the “has been purged”). > <tag><tt>config-files</tt></tag> > <item> > The package has been removed; its configuration files remain. > </item> Related to state transitions, I'd talk about the current state (is) not how we got there (has been), here and in all other state descriptions. > <tag><tt>half-installed</tt></tag> > <item> > Errors happened during installation, upgrade or removal. > Solving > them requires the package to be re-installed. > </item> ... or removed. Same comment about state transitions. > <tag><tt>unpacked</tt></tag> > <item> > The files contained in the package have been successfuly > unpacked, > but the maintainer scripts have not been executed. Thus, the > files created by the maintainer scripts are not yet available. > </item> Configuration might involve changing existing files, or changing parameters through existing APIs that change, say, a database on the backend for example, so I'd avoid explicitly mentioning that files might not be available, as that's not really comprehensive. > <tag><tt>half-configured</tt></tag> > <item> > The package has been unpacked, and an error occured during the > execution of one of its maintainer scripts. > </item> Same comment about state transitions. This state could also happen during removal for example. > <tag><tt>triggers-awaited</tt></tag> > <item> > The package has been unpacked and configured, and its > installation activated some <prgn>dpkg</prgn> triggers that have > not yet been executed. > </item> I'd say that the triggers need to be processed, and not executed. Also do we need to say that those are dpkg triggers, I'd say they are just package triggers. > <tag><tt>triggers-pending</tt></tag> > <item> > Some triggers handled by this package have been activated and > are > not yet executed. > </item> Same comment about executed → processed. > <tag><tt>installed</tt></tag> > <item> > The package is installed, no further action is required. > </item> > </taglist> The “no further action is required” seems a bit confusing, to me it reads as there's nothing else to be done to the package ever again, not even upgrades or removals. :) Hope that helps. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org