On Fri, Jul 12, 2013 at 10:19 PM, Simon Gomizelj
2) Complete list of when hooks can be run. Current list:
PreRemove PostRemove PreInstall PostInstall Transaction
Since you mentioned the texinfo later on, will you be able to distinguish in a hook between an install and an upgrade?
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?
And what actually stopping pacman from detecting if any new hooks have been installed between the install and post-install steps? Then you could use it right away.
Hello pacman devs, I'm glad this is taking shape. Although you need to help me understand the approach you have in mind first, since what I imagine probably looks a bit different from what you have in mind: Hooks could each just be an array of strings which are fed by packages' metadata. When two packages provide the same hook, they overwrite the same string/pointer. The code could be stored in both packages, which could be solved on the maintainer's side by (sym-)linking the same file - or they could each just be (a placeholder for) an additional url which is then downloaded and run exactly once. An additional feature might be if the code itself would be stored as the hook's identifier, since that would ensure similar hooks would not collide accidentally. Which is not optimal in a case when you essentially do the same thing with slightly different cli arguments. And that leads me to an actual question of interest: Will there be a way to search for hooks/list them and analyze collisions as well as essentially the same things with different whitespace? cheers! mar77i