Josselin Mouette writes ("Re: Triggers in menu"):
> Le mercredi 04 juin 2008 à 16:33 -0400, Joey Hess a écrit :
> > The current triggers code does not call the triggered script each time a
> > file is touched. The triggered script is called once at the end of the
> > dpkg run, and once after the set of changed packages are unpacked. (I'm
> > not sure why the latter call happens.)
>
> I also noticed the python-support trigger is run after unpack phase, not
> at the end of the dpkg run like it should (this leads to some
> missing .pyc files when first installing a package). If I triggered it
> explicitly again in the postinst (like update-menus does), it would make
> it run twice, meaning one too much.
Firstly, triggers are never guaranteed not to run. The whole point is
that they can be triggered by almost anything, and the system might
choose to run them even when some of the triggering packages are in a
bad state.
Obviously it would be better if dpkg could avoid running triggers too
often but this is a performance problem, not a correctness problem.
All trigger processing MUST be capable of operating correctly even if
some of the packages involved are only unpacked.
> Both issues could be avoided if dpkg delayed triggers until the end of
> the run.
dpkg does try to do this but there are various reasons why triggers
might run early. For example, apt might run dpkg more than once and
if the first run isn't given the right options to suppress trigger
processing dpkg will do them before exiting.
Or the dependencies might lead dpkg to conclude that it is necessary
to run some of the triggers now.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
