[pacman-dev] Hooks for pacman

[Eric Bélanger]

On Tue, Jan 27, 2009 at 7:57 PM, Allan McRae <allan at archlinux.org> wrote:
> 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
>

How will you handle things like gconfpkg
(/usr/share/pacman/proto-gnome.install) ? You need to pass the
pkgname. Will there be a "per package" hook? Or will you just use the
"per file" hook with the pkgname as argument. Just wanted to bring
that out.