[pacman-dev] So many HOOK puns could go here!

[Martti Kühne]

On Fri, Jul 12, 2013 at 10:19 PM, Simon Gomizelj <simongmzlj at gmail.com> wrote:
>> 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