On 07/06/13 at 01:08am, Allan McRae wrote: > > > Looking at the ini parsing patch yesterday motivated me to get hooks > implemented. But first we need to completely flesh out the details. > This is too complex of a change to make up as we go along. > > >From the mention of the previous patch, you should be able to figure out > the format I am pushing... > > Look here: > https://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks > > > Questions to answer: > > 1) Should hooks have a defined suffix. > PRO: Avoids .pac{save,new} conflicts > CON: There should be none (adjustments made in /etc) >
I would vote for a suffix just as a precaution. > > 2) Complete list of when hooks can be run. Current list: > > PreRemove > PostRemove > PreInstall > PostInstall > Transaction > > I guess we should add Pre/Post suffix to Transaction for generality. > Any more needed? > > > 3) Trigger. In the wiki I have "File" and "Package" to specify > triggers, allowing wildcards. These can be suffixed with > Install/Upgrade/Removal. Note that any operation can be triggered by > using e.g "PackageInstall = *". Does that seem general enough? > There is some redundancy here. Do we need Install/Remove/Upgrade in both the "when" and the trigger? > > 4) Should File hooks run immediately after the file or at the end of the > package. At the end of the package fits in with out current install > scripts ad so would be easier to implement. Can anyone think of a > situation with directly after the file is preferable? > I think all of the "when"s should mean the same thing whether the trigger is a file or a package. If we discover we need hooks that run immediately after a file is modified we should add a separate "when" for that. > > 5) How should we handle packages installing a new hook? e.g. In Arch, > texinfo will carry the install-info hook. I think it will still need a > post_install script to add all the info files installed before texinfo > was to the info directory, but then the hook install should be > recognised and act on any packages installed after that. Reasonable? > I think hooks have to be immediately recognized as you describe. Otherwise, it seems like it would be difficult to ever transition from using an install script to a hook. > > 6) Any other comments? > Hooks have the potential to replace install scripts altogether; is that the intent or do you just want to supplement them? > > My plan is: > 1) Finalise format (and I will make executive decisions here if > bikeshedding occurs...) > 2) Get the ini parsing patches into shape > 3) Get the parsing of hook files occuring > 4) Get transaction based hooks running > 5) Get pre/post file/package install hooks running > > Allan
