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

[Allan McRae]

Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
> Hello Allan,
>
> Am Freitag, den 11.09.2009, 20:38 +1000 schrieb 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.
>>     
>
> ...because of this i called it "design concept"...
>
>   
>>> 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
>>     
>
> The firefox one doesn't look like an example that would be used by
> anything other than the firefox package itself...
>   

Yes - but it is an actual example a script many people do run everytime 
a package is updated.  Obviously that would be a user provided hook and 
not provided by the firefox package.

>   
>> 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.
>>     
>
> Got to this impression because there is a single config file in which a
> hook has to be configured before it could be activated. The only way to
> achieve such a configuration in a way that works without
> user-intervention would be to wrap it all inside of one hook-package or
> things such a full system installation would end up without working
> hooks to execute. I apologize if my impression is wrong...
>   

That was an idea put out there because I basically do not want my info 
page database updated (the most common install file task in Arch).  This 
could probably be achieved without a config file by removing execute 
permissions from the hooks script or adding the script to the noextract 
in pacman.conf, or in a multitud of ways.  And now that concern has been 
flagged, the wiki page can be adjusted. 

These are the first comments made on the hooks idea since Februrary 
despite much advertising of the potential of implementing this on my 
behalf.  It is good to see some real discussion of implementation issues 
starting.

Allan