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

[Marc - A. Dahlhaus]

Xavier schrieb:
> On Sat, Sep 12, 2009 at 10:29 PM, Marc - A. Dahlhaus <mad at wol.de> wrote:
>> Please take a closer look at the proposed events and what it means in an
>> implementation to get them going on large transaction like a full system
>> installation (copied from the wiki):
>>
>>    * Install - run on installation of a matching file/package
>>    * PostInstall - run after installation of a matching file/package
>>    * PreRemove - run prior to removal of a matching file/package
>>    * PostRemove - run after to removal of a matching file/package
>>    * Transaction - run at end of transaction involving at least one matching
>> file
>>
>> I think that to get there for all of them, you have to constantly rescan the
>> hook.d directory during the whole transaction to load the freshly added
>> configurations and hooks and also have to rescan the whole list of already
>> installed or removed files in the running transaction for every freshly
>> added hook to solve the chicken-egg problems and installation of new hooks
>> during transaction.
>>
> 
> You are right, I was thinking about these problems.
> I guess I would just ignore the chicken-eggs problem (we already have
> to deal with this anyway with the current scriptlets, and it seems to
> work good enough ...), and also limit the features and functionality
> to make the implementation more doable :)

mhm... i have to think more about it...

The chicken-egg problems in the current scriptlets, well... i solve them 
using a trigger :-P

> We do not have to rescan the whole hooks.d directory, we could simply
> monitor files added there, and just reload this file. And this new
> hook would only be applied for the following packages.

inotify or FAM based?

FAM would be the more portable way and gamin would use inotify on linux...

>> As i couldn't convince you even a little bit at all that triggers would be a
>> nice thing to have in pacman so far instead of having a draft for something
>> that nobody wants to implement at the moment, i'll go ahead and implement it
>> tomorrow as i want to use such a functionality better sooner than later...
>>
>> If anybody is interested in it and wants to test it, drop me a line...
>>
> 
> this thread is getting huge, I think one of my mail got lost in the
> deep, when I was thinking about alternatives to implement your trigger
> idea :

That one was slipped into another mailbox here (by a keyword filter on 
the string "Edit : " as we use it in our svn commit mails)...

> Otherwise, it seems that Marc is saying that install scriptlets are
> fine, and he wants to add two functionality :
> 1) transaction level hook
> 2) sharing code
> 
> 1 could be even more easily achieved by just defining a new function
> in scriptlets, eg transaction()

This would make the case impossible where you want to run a common task 
only once for the whole transaction even if more than one package wants 
the workload (eg. mkinitramfs after kernel got updated and some modules 
got updated or installed during the same transaction) as transaction() 
would run for every package defining it...

> 2 could be achieved with function libraries (see
> http://bugs.archlinux.org/task/10375)

I thought of something like that for scriptlets also. My plan was to 
just source a script with common functions into the scriptlet execs 
before the scriptlet itself gets sourced into the running sh...

For makepkg i had sourcing of some helper functions for placing sysvinit 
symlinks into rc?.d (was the most common code duplication here) in the 
PKGBUILDs but as we migrated over to upstart so we don't needed that 
anymore...

> Again here, it is not clear to me which method is better, I am just
> throwing out ideas.

Well, so far i got much headwind against the trigger idea...


Marc