Comment 13 for bug 1824255

Chris, if the snap.yaml does not have an entry for the hook, it is known as an implicit hook, and it should basically operate the same way as an explicitly declared hook in the snap.yaml without any plugs/environment set (but there have been bugs about this before). So it is not necessary to explicitly declare the hook in the snap.yaml or the snapcraft.yaml for snapd to use it at runtime.

> It _appears_ to me that a corresponding entry for snap[craft].yaml is required only if you have extra configuration parameters required for the hook (e.g. plugs).

I think this understanding is correct today, but see below for how I think this should change.

IMHO the expected resolution to this bug is that:

1. snapcraft allows declaring command-chains for hooks in the snapcraft.yaml and this works the same as doing so in the snap.yaml, where if you specify adapter: full, then the command-chain specified in the snapcraft.yaml gets pre-pended with the snapcraft-runner
2. snapcraft auto-generates the command-chain in the snap.yaml with snapcraft-runner and the specified hook even when there is no explicit hooks section set in the snapcraft.yaml (I think it's reasonable to only do this behavior when the hook is generated by a snapcraft part and let implicit hooks operate the same way as they do today)

This may or may not break backwards compatibility, if it does then I think it's fine to wait until core20 (?) to make the full change. If that's the case, a short-term solution for my situation would be to include the snapcraft-runner in the generated hook today, i.e. to have the generated hook look something like:

```
#!/bin/sh
exec "$SNAP/snap/command-chain/snapcraft-runner" "$SNAP/snap/hooks/install" "$@"
```