[pacman-dev] [RFC] alpmtrigger: triggering events after all packages got installed...

[Marc - A. Dahlhaus]

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