[pacman-dev] Hooks for pacman

[Aaron Griffin]

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?