Re: Bug#582109: debian-policy: document triggers where appropriate
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
Reply to: