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

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.

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

Allan