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

Fri Sep 11 08:08:08 EDT 2009

Am Freitag, den 11.09.2009, 21:50 +1000 schrieb 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.

Interesting idea...

> >   
> >> 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. 

This exact point was raised already back on Fri 23 Jan 2009 by me...

> 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.

Hope this discussion remains as productive as it is :-)

Marc