Raphael Hertzog writes ("Re: Bug#476899: dpkg: Leaves new conffiles as
file.dpkg-new if the conffile is diverted"):
> But the content of the conffile gets real only after configuration and any
> trigger recorded during unpack might have already been processed (at the
> end of a dpkg --unpack run started by apt) while the content of the file
> didn't get replaced yet (we only have the .dpkg-new file for now).
So yes, the trigger may be called when it is not necessary. But it
will be called again later. So I don't think this is actually a bug
in dpkg.
Let me say this again as there seem to be some common misapprehension
about triggers:
* A trigger may be invoked spuriously
* A postinst which is doing trigger processing MUST NOT assume
that all relevant packages are fully installed. During trigger
processing it MAY be the case that some relevant packages are
totally broken - half unpacked, or other bad states.
> In fact, it might simply be wrong to record activation of a file-based
> trigger during unpack when we're speaking of a configuration file!
I agree that it would be better not to activate the trigger at unpack
of a conffile as the activation is unnecessary. This would be an
optimisation which would remove some unnecessary trigger processing.
HOWEVER the unnecessary processing is only saved if it takes place
before the package in question is configured. This should be by far
from the usual case, because trigger processing is supposed to be put
off until as late as possible. It isn't always at the moment because
apt doesn't quite pass dpkg the right options but that is where we
should improve things I think.
In principle it would be possible to make dpkg suppress the trigger
activation in this case. But it would be complicated: at the moment
dpkg activates the trigger as soon as it realises it might be
modifying the file, in an call which essential for other important
behaviours whenever any target filesystem object is accessed. This is
simple and reliable.
The alternative would be to defer the trigger activation during unpack
to later in the complicated `tarobject' function. This would involve
determining in for path through that function whether the trigger
should be activated. This would be possible but nontrivial and
afterwards the code would be such that it would be easy to
accidentally drop the trigger activation for certain cases. That
would lead to very hard to diagose bugs - the trigger processing would
fail to happen in obscure corner cases for reasons which were no
longer evident when the bug is discovered.
So I would think it better not to `improve' dpkg in this way - in the
long term the extra complexity and risk of bugs would outweigh the
benefit of a few fewer trigger runs.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
