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

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

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

I'll try to dig up the conclutions to which the apt maintainers got
before implementing the trigger system there it i find them...

>   I see the advantage of the config is that I 
> can forget about dealing with info pages at all and everything will be 
> handled automatically.
> 
> As you may notice, I hate packaging info pages :)

Me 2, i didn't even included them to the packages we use for a long time
because of this stupid infopages-catalog.

But i think with a triggering mechanism like the one i proposed we could
get rid of such things in a clean and elegant way without getting broken
legs due to the implementation in libalpm or pacman.

Will get my hands dirty on this one over the weekend...

thanks,

Marc