[pacman-dev] So many HOOK puns could go here!
From the mention of the previous patch, you should be able to figure out
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. 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) 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? 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? 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? 6) Any other comments? 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
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
On 06/07/13 04:20, Andrew Gregory wrote:
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.
OK. Bikeshedding time! I have added the requirement of a ".hook" suffix.
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?
No we don't... I was over thinking details without seeing the big picture. Removed.
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.
OK - I am doubting we will need that given no-one has mentioned the need with only our install scriptlets available.
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?
They will not replace install scripts altogether, but should replace those that appear multiple times. Allan
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.
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
On 19/07/13 22:13, Martti Kühne wrote:
Will there be a way to search for hooks/list them and analyze collisions as well as essentially the same things with different whitespace?
Short answer, no. You will be able to list hooks using "ls" on the relevant directory. I consider two hooks that do the same thing as being poor distribution packaging and is not an area for pacman to police. Allan
On Fri, Jul 19, 2013 at 10:26:15PM +1000, Allan McRae wrote:
On 19/07/13 22:13, Martti Kühne wrote:
Will there be a way to search for hooks/list them and analyze collisions as well as essentially the same things with different whitespace?
Short answer, no. You will be able to list hooks using "ls" on the relevant directory.
I consider two hooks that do the same thing as being poor distribution packaging and is not an area for pacman to police.
Allan
+1 to this idea. The owner of the binary run in the hook should be the owner of the hook, and this shouldn't cause any overlap. Arch specific examples: - core/mkinitcpio will ship a hook to build initramfs images after kernels are touched - extra/vim will ship with a hook to run vimdoc after plugin install/removal - fontconfig, xorg-mkfontscale, and xorg-mkfontdir will ship with hooks to run the appropriate binaries post-font install/removal... I'm curious if you can think of a situation where this wouldn't work.... Granted, with the /lib + /etc hierarchy we're plotting to offer, there is a chance of overlap, but that's an admin misconfiguration, not a pacman issue and not a packaging issue.
participants (5)
-
Allan McRae
-
Andrew Gregory
-
Dave Reisner
-
Martti Kühne
-
Simon Gomizelj