Dan McGee schrieb:
On Sat, Sep 12, 2009 at 8:52 AM, Marc - A. Dahlhaus <[email protected]> wrote:
Xavier schrieb:
On Sat, Sep 12, 2009 at 2:19 PM, Marc - A. Dahlhaus <[email protected]> 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
