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

[Marc - A. Dahlhaus [ Administration | Westermann GmbH ]]

Am Freitag, den 11.09.2009, 23:27 +1000 schrieb Allan McRae:
> Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
> > Am Freitag, den 11.09.2009, 22:30 +1000 schrieb Allan McRae:
> >   
> >> Allan McRae wrote:
> >>     
> >>> <snip>
> >>>       
> >>>>> 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...
> >>>>         
> >>> So it was... and here is the relevant part of my response:
> >>> [quote]
> >>>
> >>> ...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. [end quote]
> >>>
> >>> So I see what I was trying to do with the config file.  We could 
> >>> always have a separate config file per hook or try to cleanly join 
> >>> these together.
> >>>
> >>> Obviously this area needs more discussion and prototypes.
> >>>       
> >> Looking at your suggestion at the start if this thread, it seems you 
> >> wanted to avoid this config by adding a flag to run the script in the 
> >> PKGUILD or install file.
> >>     
> >
> > To the install scriptlet because of the pre_ and post_ hooks we have
> > there already i thought it would be a low hanging fruit for me... :o)
> >
> > It would be very much like the apt trigger mechanisn in debian today
> > with respect to the end-of-transaction hook i think...
> >
> > We would get the decoupling of common tasks from the install-scriptlets
> > that use them and remove the duplication point altogether from the desk
> > and even gain new functionality...
> >   
> 
> Reading this, I am not sure I understand your proposal. 
> 
> You suggested:
> 
> inside of a packages install-helper we would call
> "alpmtrigger pkgtrigger" to set the trigger "pkgtrigger" active.
> 
> 
> So each package needs an install file that contains just e.g. 
> "alpmtrigger infopage".  For every package that has info pages...  That 
> still sounds like duplication to me. 

Somewhere we have to activate things but we have the option of defining
default triggers that run every transaction to get rid of this
common-trigger case.

> Given all we need to currently do for the install file for info pages is 
> to copy the prototype and list the info pages to install, you suggestion 
> really is no less work.

IMO an install-info trigger should work based on ctime of files
in /usr/share/info and not based on a file-list that comes from the
triggering package like the current approach in arch.

Add all info pages that got installed or updated in the last 24h:

find /usr/share/info -type f -ctime -1 \
 -exec install-info '{}' /usr/share/info/dir 2>/dev/null

Files ctime gets updated even in the package upgrade case.
Should be a way out in this case...

And this is a trigger that could be added to a special place where it
gets executed after every transaction (eg. install the trigger script
in /usr/share/pacman/alpmtrigger/common.d and then fire up everything in
it before we exit the alpmtrigger processing)...

> > <snip>
> > Will get my hands dirty on this one over the weekend...
> >   
> 
> I would be waiting until some sort of consensus is met on how this 
> should be implemented....

I don't think that we can come to a broader consensus without actually
playing around with some proof of concept implementations...

I'll do it for fun and if it was a wasted effort in the end, so be it.


Marc