Dan McGee schrieb:
On Sat, Sep 12, 2009 at 8:52 AM, Marc - A. Dahlhaus <mad@wol.de> wrote:
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.
Hahahaha restarting daemons automatically... you haven't been here long, have you? :)
A silly example, i know ;o) This chained dependency was the fist that got trough my mind and Xavier asked for an example... (Debian does such a thing IIRC...)
Anyway, isn't it easy enough to just have the package install a dummy file somewhere that the hook is watching in order to trigger it? As long as this magical httpd-restart hook exists and is watching something like /var/lib/pacman/hooks/httpd-restart/, there is no problem.
That would work, but is more an hack to get this functionality in the hook design draft instead of a clean design... How to solve the other problems that i spotted in the hook design draft? <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... 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> Marc