Xavier schrieb:
On Sat, Sep 12, 2009 at 2:19 PM, Marc - A. Dahlhaus <mad@wol.de> wrote:
I actually have read the text on the wiki and i know that there is a transaction hook mentioned there.
Did you think about the case where a common task could be wanted if there isn't any filename based rule that could fire it up?
An example could be that a package adds some functionality that is an optional dependency for a job. If the dependency is not installed on the jobs first execution than some thinks are not done. If the optional dependency get installed at a later point it could ask for the trigger of the dependency and activate the missing things.
I argue that they should be differently handled because of situation where the "file X got installed so we need to start Y" will not work.
I read your message like 10 times, and I am not sure I understand what you are saying. Maybe if you could provide a more concrete example, it would be clearer for everyone :)
I mean there are cases where you don't have a file that gets installed which is related to the hook scripts original target of files. As the packager of the package that provides hook X also lays down the rules on which hook X get executed, there is no way for package Y if it wants to activate hook X to do so if it isn't providing any file on which hook X gets executed. An example could be that you have a Hook for Apache httpd which reacts on the filename filter "/etc/httpd/conf.d/*.conf" and does "apachectl -t && apachectl -k restart" for example. Package mod_php for example installs /etc/httpd/conf.d/mod_php.conf and everything is working fine, php gets activated and anyone could have a nice day. But now the user adds php_apc to his system which in turn only installs the file /etc/php.d/apc.ini to the system which would not activate php_apc for mod_php because the httpd-restart hook doesn't get executed. In the trigger approach the trigger is like in the real world a thing you have to push to activate it... The packager of php_apc knows if httpd is installed and mod_php is installed then i have to trigger the httpd-restart hook for example. The packager of httpd could not know how the other packages that might relay on his hook want to use it and what files should activate it. Might be a bad example because in a sysvinit world the httpd.init would do that on "service httpd restart" but i think it makes my point very clear. A user could have a self created repo with some packages that should add something by activating some hook from some upstream package... You can't handle it this way. I think the trigger approach is useful even if it it requires activation from the packagers side. Marc