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

Dan McGee dpmcgee at gmail.com
Sat Sep 12 11:48:11 EDT 2009


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? :)

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.

-Dan

-Dan


More information about the pacman-dev mailing list