Xavier schrieb:
On Sat, Sep 12, 2009 at 9:38 PM, Marc - A. Dahlhaus <mad@wol.de> wrote:
How to solve the other problems that i spotted in the hook design draft?
I think these problems are the same for hooks and triggers, and they can both be solved.
<quote> Also i still have the opinion that the configuration of a hook-script should be contained in the script itself as this is the only way that i could come up with at the moment that would activate the hook automatically on installation of the hook. Another way would be to add the hook configuration into the database and parse this info from there. But the user created hooks would only work if the user builds his own hook-package then...
packages could just install filehook config in a hook.d directory
Another problem with hooks and the points on which they should be executed is that if you have a large transaction in which some packages add hooks that are needed for packages that are installed in the same transaction need to be parsed on installation time to give you the option to run the hooks on the point they should be executed. Also what about a package that wants hook X needs to be installed before the hook X is added by another package? Would be a classic chicken-egg problem i think. Triggers like i proposed them don't have this problem as they get executed after the transaction is completed. At this point all triggers are where they should be. </quote>
filehooks can also work at transaction level
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. I think that this is a huge design problem and it would be very interesting to do a clean implementation of such a thing. ;o) I don't think that the implementation of this is a fun job to do, but i also hope that you get anywhere with this draft as it would be a nice thing to have for things like info-pages... 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... As i don't want to waste more of your time with the triggers approach, i will not post it for review but i'm happy and willing to discuss more about the hook approach. ;-) Marc