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

Marc - A. Dahlhaus mad at wol.de
Sat Sep 12 09:52:31 EDT 2009


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.


Marc


More information about the pacman-dev mailing list