[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#582109: debian-policy: document triggers where appropriate


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.


Reply to: