Re: Draft spec for new dpkg "triggers" feature (v2, repost)

[Ian Jackson <ian@davenant.greenend.org.uk>]

Andreas Barth writes ("Re: Draft spec for new dpkg "triggers" feature
(v2, repost)"):
> [stuff about making update-consumer a bit clever
>  rather than using Depends]

I slept on this and I think you were right.  I went and edited the
transition plan bits of the spec and they came out cleaner and less
troublesome so I think.

You can use something like this as scrollkeeper-update, renaming the
old one to scrollkeeper-update-now:

	   #!/bin/sh -e
	   if type dpkg-trigger >/dev/null 2>&1 && \
	      dpkg-trigger /usr/share/omf; then
		 exit 0
	   fi
	   exec scrollkeeper-update-now "$@"

and I think that's what I'll recommend.

> * Ian Jackson (ian@davenant.greenend.org.uk) [070430 18:02]:
> > I think I should permit --pending but not require it.
> 
> How about making --pending optional for --configure as well then?

That might be a good idea.

> > Activation has to precede modification because otherwise the system
> > goes through a forbidden state: modified but not activiated.  These
> > should be avoided; dpkg is not supposed to ever leave the system in an
> > horrid state even if it crashes unexpectedly.
> > 
> > I'm not sure I understand your example.
> 
> Ok, I understand your reasoning.
> 
> About my example, my current understanding is (but my logic might be
> flawed, so please say so):
> 
> It is only guranteed that the trigger is activated before the file is
> being modified.

Yes.

> However, one wants to have the trigger executed after the file is
> actually changed. So, how is this guranteed? Or could there be a
> sequence of events where the trigger is executed before the file is
> being modified?

The trigger might be executed when the file had not been modified,
yes.  But only if the operation was aborted between the trigger
activation and the file modification.  In that case if the operation
is resumed to completion the trigger will be activated again and so
one of the trigger executions will definitely follow the file
modification.

Note that triggers can't be processed in the gap in between activation
and file modification because it's dpkg that's doing both of these
things and dpkg only runs once at a time, and dpkg always defers
trigger processing to the end (that being the whole point).

> > I don't think adding complexity in all of the consumer packages is the
> > best way forward.  It is IMO better in this case to add a dependency
> > (which adds a not-unreasonable constraint to upgrades) than to add
> > machinery to deal with both cases.
> 
> I expect some consumer packages to have the scripts anyways - well,
> actually, I expect different packages will do it different, independed
> of what you or I propose. :)

Quite :-).  But documents like this spec, which suggest how package
maintainers ought to do things, have a strong effect and we should try
to make them good.

Thanks again for your comments.

Ian.