On Wed, Jun 17, 2015 at 09:21:03AM +0200, Anto wrote:
> Hello Isaac,
>
> After reading http://sources.debian.net/src/dpkg/1.18.1/doc/triggers.txt/
> (over and over), it looks that dpkg-trigger is a better solution than
> monitoring /etc/init.d using inotify(). However, I still fail to understand
> some points.
>
> It looks that the only entity who has all knowledge on what is going on
> during the trigger event is dpkg. How do we forward that trigger event
> information to the triggered (or consumer) package, so that it knows which
> package (or producer) initiates that trigger and what kind of action is
> being done?
>
> For instance, we set a trigger on epoch package for any updates on
> /etc/init.d. At one point after booting with epoch, we install ntp package.
> How can we make the postint script of epoch package knows that ntp package
> is being installed and /etc/init.d/ntp file is being added? The requirement
> that needs to be fulfilled for that are, there must not be any script being
> added into ntp package and no program/script with inotify() function on
> epoch package to monitor /etc/init.d. Would that be possible?

First, I'm *not* an expert on packaging (I simply learned enough to
keep a couple PPAs going correctly) or on dpkg triggers.
I know that they exist, and that they are cumulative:
if you install four packages with init scripts, and remove three more
at the same time, a trigger does not get called for each package.

So presumably a trigger would not track the individual packages,
but rather would update the epoch configuration to match /etc/init.d
(creating entries where there are none, and removing entries that
refer to missing init scripts).

Roger Leigh may be able to answer your questions more fully--and quite
likely more accurately; I don't know who else here has a background in
this off the top of my head.

HTH,
Isaac Dunham