Re: Semantic change for dpkg triggers?

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Raphael Hertzog writes ("Semantic change for dpkg triggers?"):
> I am considering changing the default behaviour of dpkg triggers. [1]
> Currently when a package activates a trigger (except if it uses
> dpkg-trigger directly with the --no-await option, and that is a minority
> of cases), the trigerring package ends up in "triggers-awaited" status
> and it doesn't satisfy dependencies.
>
> This tends to be not needed and requires trigger processing sooner than
> what's really required in many cases. Thus I am considering to change
> this: the triggering package would directly go to the installed status
> (the old behaviour could be kept if the package implementing the trigger
> switched to another trigger directive named "interest-crucial" for example
> instead of the usual "interest").

In general, the reason for this rule about satisfying dependencies is
that a triggering package may well not be functional at all until the
trigger is run.  For example, if the triggering package T needs to be
registered with the interested package I, a package D which depends on
T may find that T does not work - and D's postinst may fail due to T
being broken.

But I can see that there might be a need for a less-restrictive
trigger, where the functionality which will be provided by trigger
processing is not crucial.  But it seems to me that whether the
functionality is crucial is at least as much a property of the
triggering package, not the interested package.

If a new behaviour is needed, it should have a new name.  Otherwise
you break existing packages.

So I would suggest:

 * New trigger directive "trigger-noawait", works like 
   dpkg-trigger --no-await 

But we do also need a way to do this for file triggers:

 * New trigger directive "interest-filenoawait" which has the
   following semantics:
      - when triggered explicitly by name by a triggering package,
        the triggering package awaits the trigger unless the
        triggering package specifies --no-await
      - when triggered implicitly by installation of a file, the
        triggering package does not await the trigger

> My question is thus: are there triggers currently in use where this
> relaxed behaviour would be wrong? Or more simply are there packages which
> are really not working before the processing of their awaited triggers?

I haven't done a survey but I would expect there to be some.

> Alternatively we could also discuss whether it would make sense
> to change the meaning of the triggers-awaited status to something where
> it would be enough to satisfy dependencies.

That would be wrong IMO.  If triggering without impeding dependencies
is required, simply going straight to "installed" is correct.

Ian.