[pacman-dev] Hooks for pacman

[Allan McRae]

Eric Bélanger wrote:
> 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.

The file that would set off the gconfpkg hook would be like 
/usr/share/gconf/schemas/pkgname.schemas. So the script will be passed 
the filename and can extract the pkgname from that reasonably easily.

Allan