~alpine/aports

2 2

[alpine-aports] Exactly when do triggers run?

Isaac Dunham <ibid.ag@gmail.com>
Details
Message ID
<20160123043942.GB8310@newbook>
Sender timestamp
1453523983
DKIM signature
missing
Download raw message
Hello,
I'm wondering what causes triggers to run.
Specifically, it seems that a trigger only runs if the watched files/dirs
are changed *by another package*.
Is this expected behavior, or a case of a situation not being expected?
(Or is it simply that the trigger does not exist during the package
upgrades?)

In case you're wondering what I'm trying to do:
I've built ted with both GTK (/usr/bin/Ted) and Motif (/usr/bin/Ted.motif)
versions.
I'd like the Motif version to automatically get a link to it if there's
not already a /usr/bin/Ted binary.
This should happen even if I do
apk add ted
apk add ted-motif
apk del ted

I've been trying to do this thus:
ted-motif provides ted
ted-motif has a trigger watching /usr/bin/Ted*

The trigger never goes off.

Experimenting, I see that "provides=$PKG" doesn't work like I thought;
it results in $PKG being replaced.
So it should work to simply install Ted.motif as Ted.

Thanks,
Isaac Dunham


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20160123230900.504e2762@vostro>
In-Reply-To
<20160123043942.GB8310@newbook> (view parent)
Sender timestamp
1453583340
DKIM signature
missing
Download raw message
On Fri, 22 Jan 2016 20:39:43 -0800
Isaac Dunham <ibid.ag@gmail.com> wrote:

> I'm wondering what causes triggers to run.
> Specifically, it seems that a trigger only runs if the watched
> files/dirs are changed *by another package*.
> Is this expected behavior, or a case of a situation not being
> expected? (Or is it simply that the trigger does not exist during the
> package upgrades?)

Trigger should run when ever package contents touch a file matching
trigger specification. When the package with trigger itself gets
installed or upgraded, the trigger is fired with all matching files
(in package database).

The trigger gets list of matching files that were modified as
arguments.

The triggers are run after all packages have been extracted and files
moved into the correct positions. The list of triggers to run is
calculated, and the triggers are sorted based on the package dependency
order. Finally the are executed serially.

> In case you're wondering what I'm trying to do:
> I've built ted with both GTK (/usr/bin/Ted) and Motif
> (/usr/bin/Ted.motif) versions.
> I'd like the Motif version to automatically get a link to it if
> there's not already a /usr/bin/Ted binary.
> This should happen even if I do
> apk add ted
> apk add ted-motif
> apk del ted
> 
> I've been trying to do this thus:
> ted-motif provides ted
> ted-motif has a trigger watching /usr/bin/Ted*
> 
> The trigger never goes off.

Yes, your watch is for the specific file; and deletion of the file does
not fire it currently.

For busybox the symlink magic works because busybox monitors
the /usr/bin path.

> Experimenting, I see that "provides=$PKG" doesn't work like I thought;
> it results in $PKG being replaced.
> So it should work to simply install Ted.motif as Ted.

Currently file deletion does not fire trigger if the match is for the
file. It does however fire if the match is against a directory. 

I suppose the above could be considered a bug. It would make more sense
to fire the trigger, and give the deleted file as argument and leave it
up to the trigger to figure out that the file does not exist anymore.

@ncopa Do you think we have triggers that'd break if we add the
match for deleted files?

Or should there be specific syntax on which type of events (add,
modify, delete) fire the trigger?

/Timo


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20160125085131.54ae8728@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20160123230900.504e2762@vostro> (view parent)
Sender timestamp
1453708291
DKIM signature
missing
Download raw message
On Sat, 23 Jan 2016 23:09:00 +0200
Timo Teras <timo.teras@iki.fi> wrote:

> On Fri, 22 Jan 2016 20:39:43 -0800
> Isaac Dunham <ibid.ag@gmail.com> wrote:
> 
> > I'm wondering what causes triggers to run.

...

> Currently file deletion does not fire trigger if the match is for the
> file. It does however fire if the match is against a directory. 
> 
> I suppose the above could be considered a bug. It would make more sense
> to fire the trigger, and give the deleted file as argument and leave it
> up to the trigger to figure out that the file does not exist anymore.
> 
> @ncopa Do you think we have triggers that'd break if we add the
> match for deleted files?

No, I don't think any triggers would break if we add match for deleted
files. I think all triggers we have so far only watches directories, so
we should be good.

> Or should there be specific syntax on which type of events (add,
> modify, delete) fire the trigger?

With the above you could easily detect if its deleted or add/modified.
I would think that is enough for most cases? I suspect that you will in
almost all cases want to handle 'modified' the same way as 'add'.

If this shows to not be enough, then maybe add that via env var in
future or similar?

-nc


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)