Xavier schrieb:
On Sat, Sep 12, 2009 at 10:29 PM, Marc - A. Dahlhaus <mad@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