[pacman-dev] Hooks for pacman

Allan McRae allan at archlinux.org
Tue Jan 27 19:57:14 EST 2009

Aaron Griffin wrote:
> On Fri, Jan 23, 2009 at 11:56 AM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
>> On Fri, Jan 23, 2009 at 9:38 AM, Allan McRae <allan at archlinux.org> wrote:
>>> Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
>>>> Am Samstag, den 24.01.2009, 00:52 +1000 schrieb Allan McRae:
>>>>> Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
>>>>>> Hello,
>>>>>> what about an approach that keeps all settings of a specific hook inside
>>>>>> the hook script itself? This would just work after deployment of a hook
>>>>>> script in /etc/pacman.d/hooks.d without any configuration file hassle.
>>>>>> The Hooks would be self contained in files that pacman could source
>>>>>> before doing anything. And if someone wants to know what a hook do and
>>>>>> when it will be used there is only one place to look.
>>>>> The one problem I see with that is that the actual script needs to be
>>>>> run.  The post_install scripts etc, just source and run the script in a
>>>>> shell.  This becomes more difficult if we have to keep information what
>>>>> files trigger the hooks to be run and when.
>>>> The point was that this way you can install new hooks with packages and
>>>> they would just work without any configuration file fiddling. It would
>>>> be cleaner for a packager in my opinion.
>>> I understood you point.  My point is that each hook need to provide the
>>> following information:
>>> 1. when to run it (per file or transaction)
>>> 2. what files trigger it running
>>> 3. a script that can be sourced and run by the shell.
>>> It is _a lot_ easier if 1 and 2 are separate from 3.  If you can propose a
>>> clean way to have them all together, then we will be happy to consider it.
>> Hmmm
>> #myhook
>> RUN=PerFile
>> PATTERN=/usr/share/info/*
>> #####
>> run () {
>>   ...
>> }
>> We could do something nasty where pacman parses the file, ignores all
>> lines that it doesn't match to '^RUN' or '^PATTERN', and possibly end
>> parsing early at some token (the ##### above)
>> Still, it's a little nasty. I almost prefer the manual config file
>> editing for a few reasons: It doesn't force the user to use these
>> hooks. *I* should have to turn on the install-info hook myself.
> One thing that just came to mind (emailing it before I forget):
> We need to differentiate between additions and removals for the "per
> trans" hooks somehow.
> Take, for instance, info files.
> On add:
> install-info /path/to/file
> On remove:
> install-info --delete /path/to/file
> The per-trans hook needs to do BOTH steps in the case of an upgrade (a
> remove then an add). Right? Or do info files work fine in this case?

I count install-info stuff as a "per file" hook rather than a per-trans 
hook because you need to pass a file name.  Per trans hooks would be 
mainly for updating font/desktop/icon databases where filenames are not 

While I cannot think of any need for a pre-transaction hook, that does 
not mean someone won't and I am willing to lean on the side of 
generality for this.


More information about the pacman-dev mailing list