[Pkg-javascript-devel] Javascript trigger design

[Guillem Jover]

Hi!

On Tue, 2014-12-02 at 06:46:33 +0800, Thomas Goirand wrote:
> On 12/01/2014 04:26 PM, Thorsten Glaser wrote:
> > No, triggers unfortunately are not that simple: if you install/upgrade
> > openstack-dashboard together with some of the packages it wants a
> > trigger on, $1="triggered" will sometimes not happen, only "configure".

> > The thing to call when triggered is the upgrade_mediawikis shell
> > function, it’s called from the “triggered” case, but also from
> > the regular “configure” case. This is suboptimal, but apparently
> > needed.

Well if you install the interested package and nothing triggers, and
you need to run the action that would normally be done when triggered
then sure, you'd also perform that action on configure.

> So if I understand well (by reading your example package), the only
> thing I have to do (for horizon) is:
> 
> 1/ Create a debian/openstack-dashboard.triggers that would contain a
> list of "interest /usr/share/javascript/<something>", for example:
> 
> interest /usr/share/javascript/jsencrypt

Please *always* consider using the -noawait (deb-triggers(5) and
dpkg-trigger(1)) variants if the triggering packages does not depend
(at “dpkg” time) on the functionality provided by the trigger, as it
simplifies the trigger handling and should avoid most possible trigger
cycles due to that.

> Is it *that* simple? I'm surprised by the "interest" thing just being
> hinted with a directory. Does this mean that if anything changes in that
> directory, then there's a trigger, and the openstack-dashboard compress
> stuff will happen?

Anything changed below that directory should activate the trigger, as
long as it is either known to dpkg, or something activates it manually
through dpkg-trigger(1).

On Tue, 2014-12-02 at 15:23:21 +0100, Thorsten Glaser wrote:
> On Tue, 2 Dec 2014, Brian May wrote:
> > There might be times when compress is run twice.  e.g. when
> 
> It does, yes. I wonder about that too. Can a package trigger itself?

It _can_ (as in it is possible), but depending on how it is done that
*might* produce trigger cycles.

> > (e.g. you could explicitly raise the trigger inside the configure event,
> > however that will trigger all applications that have an interest
> > in /usr/share/javascript/jsencrypt which is probably not desirable)

If your only intention is to avoid duplicated work, then yeah that
might defeat it by shifting the load somewhere else.

> Maybe otherwise: both postinst and the /usr/share/javascript/jsencrypt
> trigger handler trigger a 'openstack-dashboard-meta' trigger, which
> does the actual work?

All triggers for an interested package are coalesced, and doing the
above would most probably create a cycle. You'd only need to activate
an explicit (private) trigger from the configure, and that would get
coalesced with any file triggers, which should avoid the duplication
you are seeing I guess. (Well as long as I've understood correctly
what you are trying to achieve. :)

Thanks,
Guillem