[pacman-dev] [RFC] alpmtrigger: triggering events after all packages got installed...

[Allan McRae]

Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
> Am Freitag, den 11.09.2009, 11:30 +0200 schrieb Xavier:
>   
>> On Fri, Sep 11, 2009 at 11:18 AM, Marc - A. Dahlhaus [ Administration
>> | Westermann GmbH ] <mad at wol.de> wrote:
>>     
>>> Hello List,
>>>
>>>
>>> currently i'm working on adding a trigger infrastructure to
>>> libaplm/pacman to get rid of workload during upgrades or installations
>>> that runs more than a single time.
>>>
>>> Good examples for such jobs would be:
>>>
>>> - depmod after module installations
>>> - mkinitramfs after module installations
>>> - catalog-updates for fonts or infopages
>>> etc...
>>>
>>>
>>> My current plan is to create a helper script called "alpmtrigger"
>>> wich handles the work of setting the triggers and executing the triggers
>>> after pacman is done with installation.
>>>
>>> How would it work?
>>> Draft:
>>>
>>> A package that adds a trigger to the system installs a trigger script
>>> that do all the work needed into a "/usr/share/pacman/alpmtrigger" dir.
>>>
>>> inside of a packages install-helper we would call
>>> "alpmtrigger pkgtrigger" to set the trigger "pkgtrigger" active.
>>> alpmtrigger would do "touch /var/somewhere/alpmtrigger/pkgtrigger" wich
>>> would create the file if it not exists already.
>>>
>>> A hook to execute "alpmtrigger" (without params?) would need to be added
>>> after the _alpm_run_chroot(root, "/sbin/ldconfig"); call in function
>>> _alpm_ldconfig inside of lib/libalpm/util.c to actualy scan the contents
>>> of /var/somewhere/alpmtrigger, and for each filename in it check
>>> if /usr/share/pacman/alpmtrigger/filename exists and if it is and is
>>> executable run the trigger. After the trigger is done and retuned
>>> without error, the file /var/somewhere/alpmtrigger/filename gets
>>> removed.
>>>
>>> Any suggestions, comments or somebody else working on such a thing?
>>>
>>>
>>>       
>> see http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks
>>     
>
> I think this design concept will not work in real world use cases.
>
>   

Note that the design document I started is far from the final 
version...  it was written to get discussion going and see what it could 
be used for.


> Problems i spotted:
>
> - Hooks should be provided by the packages that actualy contain the
> tools that the hook has to do.
>
>   

Sure, but how is the opposite implied by what is written.  Texinfo could 
(and should) provide the hook for updating the info databse, etc.   I 
think this is you main point throughout and that seems to be a 
misunderstanding.

> - Hooks should get installed by placing a file into an apropriate
> location and not by adding them to a single config-file (manual
> intervention of the user required or every new hook a new hooks package
> has to be made)
>   

 From the design document, hook were added as a single file to the 
/etc/pacman.d/hooks.d/ directory.   Adding the hook to a config file was 
to control if a user wanted that hook run.   e.g. I really do not give a 
crap about updating the info page database so I would not set it to 
run.   This can probably be improved (as could many things in that wiki 
page).


> - I don't think that so many points to add a hook are really needed in a
> real world...
>   

Here is a list of "hooks" that would be useful for Arch packaging.  I 
know this is Arch specific but it should give an idea of real world use 
cases:

PostInstall:
    [gconf-install] - install gconf files
    [info-install] - add info pages to info directory file
    [man-install] - add man pages to db

PreRemove:
    [gconf-remove] - remove gconf files
    [info-remove] - remove info pages from info directory file
    [man-remove] - remove man pages from db   

Transaction:
    [depmod] - can we do that as a hook
    [desktop] - update desktop database
    [font] - update the font cache
    [icon] - update gtk icon cache or xdg-icon-resource (how to choose?)
    [mime] - update mime database
    [tex-file] - texconfig-sys rehash
    [tex-font] - updmap-sys
    [vim] - update vim help tags
    [xpdf] - update /etc/xpdfrc

Install:
    [firefox] automatically run branding firefox script

That covers actions that would use the majority of the proposed hook points.

<snip>
>> Before implementing anything, I would like to see the maximum of
>> actions which are currently done in real package scriptlets converted
>> to the new hook system. So that we are sure we have a good coverage.
>>     
>
> nothing to add here, as this is an arch only argument, i don't use arch
> and pacman development should done with other things than "how useful is
> XYZ for arch" in mind IMO...
>
>   

You are free to provide your non-Arch use cases so we can see real world 
examples.

> <snip>
> I think that a solution is needed that removes work from the package
> maintainers and not add another thing they have to think about and have
> to collaborate on like the single hook package what would be fruit of
> implementing the Packman_Hooks thing...
>   

As I said above, I really do not understand why you think we would have 
to provide a hooks package and not provide hooks with the appropriate 
package.

Allan