[pacman-dev] [RFC] alpmtrigger: triggering events after all packages got installed...

[Marc - A. Dahlhaus]

Xavier schrieb:
> On Fri, Sep 11, 2009 at 3:27 PM, Allan McRae <allan at archlinux.org> wrote:
>> Reading this, I am not sure I understand your proposal.
>> You suggested:
>>
>> inside of a packages install-helper we would call
>> "alpmtrigger pkgtrigger" to set the trigger "pkgtrigger" active.
>>
>>
>> So each package needs an install file that contains just e.g. "alpmtrigger
>> infopage".  For every package that has info pages...  That still sounds like
>> duplication to me.
>> Given all we need to currently do for the install file for info pages is to
>> copy the prototype and list the info pages to install, you suggestion really
>> is no less work.
>>
> 
> Another important question here :
> how are user hooks defined then ?

I think we should distinct between triggers and what they are/provide 
and what hooks are/provide.



The trigger approach is used to fire up well defined common tasks at a 
later point in the installation.

Triggers are by design part of the package that provides them. They 
allow other packages to make usage of its functionality for common tasks 
at the end of a running transaction. They try to do such a common task 
one time during the whole transaction. There is no ordinary user of the 
distribution involved here by design as it has to just work for the user 
without user intervention.



The hook approach is used to fire up tasks on specific events during the 
package installation.

Hooks are placed at defined spots to the codebase of libalpm and provide 
chains with as much hook-rules as got configured for it. The rules 
consists of "filename that got installed" based fire up of scripts.
(I think the remaining two hook types "once per transaction" and "for a 
given package" would be more or less like what i wrote about triggers above)



The question is do we really need this chain of rules for each proposed 
hook in libalpm thing which needs to scan for all the defined filename 
or package-name rules and will it be worth the effort to implement it if 
just a few packages ever will make use of the hooks. How often will we 
look at matching hook rules during normal operation? I'll bet not quite 
often.

I think this approach would also waste quite a few resources on every 
transaction to search for matches without even knowing if some package 
would trigger such an event. It has to do that every time as there is no 
"i want this hook to get fired up" action from the package-side as it 
would in the trigger approach. I think to list the content of one or 
more directories and fire up scriptlets based on files found would 
clearly outperform the scanning of every file that gets installed based 
on N rules we need to match against.

I think we could achieve anything we could think of with the trigger 
approach from the packagers perspective except giving the user the 
ability to install hooks on this users self defined event-rules...

If a user really wants to add a script which fires up if some filename 
based event is fulfilled than this user should take a look at the incron 
package and use it for what it was made IMO.



Thats the way i look at the situation currently, but i'm open to any 
others opinion of course.

Thanks,


Marc