[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
needed.
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.
Allan
More information about the pacman-dev
mailing list