[pacman-dev] Hooks for pacman
Hi all, A new feature I am ever so slightly obsessed about at the moment is the possibility of having hooks in pacman for doing common tasks in install files. e.g. adding info pages to directory, updating font/icon/.desktop cache, gconf stuff... So, how would this be implemented? Here is my outline: Two types of hooks would be needed for both install and remove. One type that is run for every matching file (e.g. info install) and one type that is run once per transaction (e.g. font cache update). These could be stored in /etc/pacman.d/hooks/ with an index of hooks in /etc/pacman.d/hooks.conf. The .conf file could look something like: [add] PerFile = infopage /usr/share/info/ PerTrans = fontcache /usr/share/fonts/ [remove] ... That needs improvement, but that covers the information that needs presented - whether the hook is run per file or per transaction, the name of the hook and the directory whose files set off this hook. Maybe the conditions that set the hook off should be in the actual hook file. I guess the actual hook would look look just like: hook() { do stuff here... } I figure we must already generate a list of all the files being added/removed during conflict checks, so we would "just" need to scan that list for what hooks need to be run and actually run them. Anyway, I thought I would post this idea here so I could get more feedback on the implementation and maybe convince someone to code it... Allan
On Thu, Jan 22, 2009 at 9:15 AM, Allan McRae <allan@archlinux.org> wrote:
Hi all,
A new feature I am ever so slightly obsessed about at the moment is the possibility of having hooks in pacman for doing common tasks in install files. e.g. adding info pages to directory, updating font/icon/.desktop cache, gconf stuff... So, how would this be implemented? Here is my outline:
Two types of hooks would be needed for both install and remove. One type that is run for every matching file (e.g. info install) and one type that is run once per transaction (e.g. font cache update). These could be stored in /etc/pacman.d/hooks/ with an index of hooks in /etc/pacman.d/hooks.conf. The .conf file could look something like:
[add] PerFile = infopage /usr/share/info/ PerTrans = fontcache /usr/share/fonts/
[remove] ...
That needs improvement, but that covers the information that needs presented - whether the hook is run per file or per transaction, the name of the hook and the directory whose files set off this hook. Maybe the conditions that set the hook off should be in the actual hook file.
I guess the actual hook would look look just like:
hook() { do stuff here... }
I figure we must already generate a list of all the files being added/removed during conflict checks, so we would "just" need to scan that list for what hooks need to be run and actually run them.
Anyway, I thought I would post this idea here so I could get more feedback on the implementation and maybe convince someone to code it...
This is much better than the ideas Dan and I fleshed out last time we talked about this. One or two nitpicks, though: a) [add] and [remove] seem to simple. How about [AddHooks] and [RemoveHooks]? b) It'd be nice to use fnmatch patterns (globs) for the file paths. c) Instead of a function, it makes more sense to just make a script that takes the files as args, and only run it if it is executable (assume -x is disable) Other than that, I really like the PerFile and PerTrans distinction. Questions: Where will these hooks reside? /etc/pacman.d/hooks/ ? When modifying the config parsing, can you ensure 'Include' works here? That would allow us to ship some stock hooks for info files and the like, and users would simply include them.
Aaron Griffin wrote:
On Thu, Jan 22, 2009 at 9:15 AM, Allan McRae <allan@archlinux.org> wrote:
Hi all,
A new feature I am ever so slightly obsessed about at the moment is the possibility of having hooks in pacman for doing common tasks in install files. e.g. adding info pages to directory, updating font/icon/.desktop cache, gconf stuff... So, how would this be implemented? Here is my outline:
Two types of hooks would be needed for both install and remove. One type that is run for every matching file (e.g. info install) and one type that is run once per transaction (e.g. font cache update). These could be stored in /etc/pacman.d/hooks/ with an index of hooks in /etc/pacman.d/hooks.conf. The .conf file could look something like:
[add] PerFile = infopage /usr/share/info/ PerTrans = fontcache /usr/share/fonts/
[remove] ...
That needs improvement, but that covers the information that needs presented - whether the hook is run per file or per transaction, the name of the hook and the directory whose files set off this hook. Maybe the conditions that set the hook off should be in the actual hook file.
I guess the actual hook would look look just like:
hook() { do stuff here... }
I figure we must already generate a list of all the files being added/removed during conflict checks, so we would "just" need to scan that list for what hooks need to be run and actually run them.
Anyway, I thought I would post this idea here so I could get more feedback on the implementation and maybe convince someone to code it...
This is much better than the ideas Dan and I fleshed out last time we talked about this. One or two nitpicks, though:
a) [add] and [remove] seem to simple. How about [AddHooks] and [RemoveHooks]? b) It'd be nice to use fnmatch patterns (globs) for the file paths. c) Instead of a function, it makes more sense to just make a script that takes the files as args, and only run it if it is executable (assume -x is disable) Other than that, I really like the PerFile and PerTrans distinction.
All good suggestions. I went for the function idea so I could reused code for running install scripts. I have never look at that code so I don't know whether that would be a good or bad idea. Thinking about this some more, per transaction hooks really only need ran per transaction... I.e. there is probably no need for the distinction within [AddHooks] of PerFile and PerTrans. All the examples I used for run once hook will look the same for both add and remove. Instead, we could have [AddHooks], [RemoveHooks] and [TransHooks].
Questions: Where will these hooks reside? /etc/pacman.d/hooks/ ?
Sure.
When modifying the config parsing, can you ensure 'Include' works here? That would allow us to ship some stock hooks for info files and the like, and users would simply include them.
Can you provide an example of what you think the config would look like. I have a fair guess at what you mean but clarification would be good. I will make a wiki page with config mock-ups and a few example hooks given this is probably the most important part to get right of the whole proposal. Allan
On Thu, Jan 22, 2009 at 6:29 PM, Allan McRae <allan@archlinux.org> wrote:
Aaron Griffin wrote:
On Thu, Jan 22, 2009 at 9:15 AM, Allan McRae <allan@archlinux.org> wrote:
Hi all,
A new feature I am ever so slightly obsessed about at the moment is the possibility of having hooks in pacman for doing common tasks in install files. e.g. adding info pages to directory, updating font/icon/.desktop cache, gconf stuff... So, how would this be implemented? Here is my outline:
Two types of hooks would be needed for both install and remove. One type that is run for every matching file (e.g. info install) and one type that is run once per transaction (e.g. font cache update). These could be stored in /etc/pacman.d/hooks/ with an index of hooks in /etc/pacman.d/hooks.conf. The .conf file could look something like:
[add] PerFile = infopage /usr/share/info/ PerTrans = fontcache /usr/share/fonts/
[remove] ...
That needs improvement, but that covers the information that needs presented - whether the hook is run per file or per transaction, the name of the hook and the directory whose files set off this hook. Maybe the conditions that set the hook off should be in the actual hook file.
I guess the actual hook would look look just like:
hook() { do stuff here... }
I figure we must already generate a list of all the files being added/removed during conflict checks, so we would "just" need to scan that list for what hooks need to be run and actually run them.
Anyway, I thought I would post this idea here so I could get more feedback on the implementation and maybe convince someone to code it...
This is much better than the ideas Dan and I fleshed out last time we talked about this. One or two nitpicks, though:
a) [add] and [remove] seem to simple. How about [AddHooks] and [RemoveHooks]? b) It'd be nice to use fnmatch patterns (globs) for the file paths. c) Instead of a function, it makes more sense to just make a script that takes the files as args, and only run it if it is executable (assume -x is disable) Other than that, I really like the PerFile and PerTrans distinction.
All good suggestions. I went for the function idea so I could reused code for running install scripts. I have never look at that code so I don't know whether that would be a good or bad idea.
The code simply runs bash and does the following: . /my/install/scriptlet; post_install $version Note the dot and semicolon are newer. The previous code didn't have it - thus the reason why you see the "op=$1" malarky in older scriptlets.
Thinking about this some more, per transaction hooks really only need ran per transaction... I.e. there is probably no need for the distinction within [AddHooks] of PerFile and PerTrans. All the examples I used for run once hook will look the same for both add and remove. Instead, we could have [AddHooks], [RemoveHooks] and [TransHooks].
That's a good point - the per-transaction hooks are probably able to handle added AND removed files. If not, it is a bash script, so i'm sure something could be done. Worst case scenario, a very complex hook could use all three - write some info to a temp file on add or remove, then use the file in the trans hook.
When modifying the config parsing, can you ensure 'Include' works here? That would allow us to ship some stock hooks for info files and the like, and users would simply include them.
Can you provide an example of what you think the config would look like. I have a fair guess at what you mean but clarification would be good.
[AddHooks] Include = /etc/pacman.d/hooks/gnome-hooks ... # gnome-hooks PerFile = mime-database-stuff PerFile = scrollkeeper-stuff PerFile = update-desktop-db I guess with the removal of PerFile/PerTransaction, this gets a little more weird... perhaps we could allow multiple sections of the same name to add to the previous one. That is: [AddHooks] something Include = /etc/pacman.d/hooks/gnome-hooks ... #gnome-hooks [AddHooks] above-gnome-stuff [RemoveHooks] more-stuff
On Thu, Jan 22, 2009 at 6:51 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, Jan 22, 2009 at 6:29 PM, Allan McRae <allan@archlinux.org> wrote:
Aaron Griffin wrote:
On Thu, Jan 22, 2009 at 9:15 AM, Allan McRae <allan@archlinux.org> wrote:
Hi all,
A new feature I am ever so slightly obsessed about at the moment is the possibility of having hooks in pacman for doing common tasks in install files. e.g. adding info pages to directory, updating font/icon/.desktop cache, gconf stuff... So, how would this be implemented? Here is my outline:
Two types of hooks would be needed for both install and remove. One type that is run for every matching file (e.g. info install) and one type that is run once per transaction (e.g. font cache update). These could be stored in /etc/pacman.d/hooks/ with an index of hooks in /etc/pacman.d/hooks.conf. The .conf file could look something like:
[add] PerFile = infopage /usr/share/info/ PerTrans = fontcache /usr/share/fonts/
[remove] ...
That needs improvement, but that covers the information that needs presented - whether the hook is run per file or per transaction, the name of the hook and the directory whose files set off this hook. Maybe the conditions that set the hook off should be in the actual hook file.
I guess the actual hook would look look just like:
hook() { do stuff here... }
I figure we must already generate a list of all the files being added/removed during conflict checks, so we would "just" need to scan that list for what hooks need to be run and actually run them.
Anyway, I thought I would post this idea here so I could get more feedback on the implementation and maybe convince someone to code it...
This is much better than the ideas Dan and I fleshed out last time we talked about this. One or two nitpicks, though:
a) [add] and [remove] seem to simple. How about [AddHooks] and [RemoveHooks]? b) It'd be nice to use fnmatch patterns (globs) for the file paths. c) Instead of a function, it makes more sense to just make a script that takes the files as args, and only run it if it is executable (assume -x is disable) Other than that, I really like the PerFile and PerTrans distinction.
All good suggestions. I went for the function idea so I could reused code for running install scripts. I have never look at that code so I don't know whether that would be a good or bad idea.
The code simply runs bash and does the following: . /my/install/scriptlet; post_install $version
Note the dot and semicolon are newer. The previous code didn't have it - thus the reason why you see the "op=$1" malarky in older scriptlets.
Thinking about this some more, per transaction hooks really only need ran per transaction... I.e. there is probably no need for the distinction within [AddHooks] of PerFile and PerTrans. All the examples I used for run once hook will look the same for both add and remove. Instead, we could have [AddHooks], [RemoveHooks] and [TransHooks].
That's a good point - the per-transaction hooks are probably able to handle added AND removed files. If not, it is a bash script, so i'm sure something could be done. Worst case scenario, a very complex hook could use all three - write some info to a temp file on add or remove, then use the file in the trans hook.
When modifying the config parsing, can you ensure 'Include' works here? That would allow us to ship some stock hooks for info files and the like, and users would simply include them.
Can you provide an example of what you think the config would look like. I have a fair guess at what you mean but clarification would be good.
[AddHooks] Include = /etc/pacman.d/hooks/gnome-hooks ...
# gnome-hooks PerFile = mime-database-stuff PerFile = scrollkeeper-stuff PerFile = update-desktop-db
I guess with the removal of PerFile/PerTransaction, this gets a little more weird... perhaps we could allow multiple sections of the same name to add to the previous one. That is:
[AddHooks] something
Include = /etc/pacman.d/hooks/gnome-hooks ...
#gnome-hooks [AddHooks] above-gnome-stuff
[RemoveHooks] more-stuff
Let's get this in a wiki, I think that is a great idea to get it hashed out and make sure we aren't forgetting about certain scenarios. Overall this seems like a workable approach. -Dan
Am Donnerstag, den 22.01.2009, 21:04 -0600 schrieb Dan McGee:
On Thu, Jan 22, 2009 at 6:51 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, Jan 22, 2009 at 6:29 PM, Allan McRae <allan@archlinux.org> wrote:
Aaron Griffin wrote:
On Thu, Jan 22, 2009 at 9:15 AM, Allan McRae <allan@archlinux.org> wrote:
Hi all,
A new feature I am ever so slightly obsessed about at the moment is the possibility of having hooks in pacman for doing common tasks in install files. e.g. adding info pages to directory, updating font/icon/.desktop cache, gconf stuff... So, how would this be implemented? Here is my outline:
Two types of hooks would be needed for both install and remove. One type that is run for every matching file (e.g. info install) and one type that is run once per transaction (e.g. font cache update). These could be stored in /etc/pacman.d/hooks/ with an index of hooks in /etc/pacman.d/hooks.conf. The .conf file could look something like:
[add] PerFile = infopage /usr/share/info/ PerTrans = fontcache /usr/share/fonts/
[remove] ...
That needs improvement, but that covers the information that needs presented - whether the hook is run per file or per transaction, the name of the hook and the directory whose files set off this hook. Maybe the conditions that set the hook off should be in the actual hook file.
I guess the actual hook would look look just like:
hook() { do stuff here... }
I figure we must already generate a list of all the files being added/removed during conflict checks, so we would "just" need to scan that list for what hooks need to be run and actually run them.
Anyway, I thought I would post this idea here so I could get more feedback on the implementation and maybe convince someone to code it...
This is much better than the ideas Dan and I fleshed out last time we talked about this. One or two nitpicks, though:
a) [add] and [remove] seem to simple. How about [AddHooks] and [RemoveHooks]? b) It'd be nice to use fnmatch patterns (globs) for the file paths. c) Instead of a function, it makes more sense to just make a script that takes the files as args, and only run it if it is executable (assume -x is disable) Other than that, I really like the PerFile and PerTrans distinction.
All good suggestions. I went for the function idea so I could reused code for running install scripts. I have never look at that code so I don't know whether that would be a good or bad idea.
The code simply runs bash and does the following: . /my/install/scriptlet; post_install $version
Note the dot and semicolon are newer. The previous code didn't have it - thus the reason why you see the "op=$1" malarky in older scriptlets.
Thinking about this some more, per transaction hooks really only need ran per transaction... I.e. there is probably no need for the distinction within [AddHooks] of PerFile and PerTrans. All the examples I used for run once hook will look the same for both add and remove. Instead, we could have [AddHooks], [RemoveHooks] and [TransHooks].
That's a good point - the per-transaction hooks are probably able to handle added AND removed files. If not, it is a bash script, so i'm sure something could be done. Worst case scenario, a very complex hook could use all three - write some info to a temp file on add or remove, then use the file in the trans hook.
When modifying the config parsing, can you ensure 'Include' works here? That would allow us to ship some stock hooks for info files and the like, and users would simply include them.
Can you provide an example of what you think the config would look like. I have a fair guess at what you mean but clarification would be good.
[AddHooks] Include = /etc/pacman.d/hooks/gnome-hooks ...
# gnome-hooks PerFile = mime-database-stuff PerFile = scrollkeeper-stuff PerFile = update-desktop-db
I guess with the removal of PerFile/PerTransaction, this gets a little more weird... perhaps we could allow multiple sections of the same name to add to the previous one. That is:
[AddHooks] something
Include = /etc/pacman.d/hooks/gnome-hooks ...
#gnome-hooks [AddHooks] above-gnome-stuff
[RemoveHooks] more-stuff
Let's get this in a wiki, I think that is a great idea to get it hashed out and make sure we aren't forgetting about certain scenarios.
Overall this seems like a workable approach.
-Dan
Hello, what about an approach that keeps all settings of a specific hook inside the hook script itself? This would just work after deployment of a hook script in /etc/pacman.d/hooks.d without any configuration file hassle. The Hooks would be self contained in files that pacman could source before doing anything. And if someone wants to know what a hook do and when it will be used there is only one place to look. Marc
Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
Hello, what about an approach that keeps all settings of a specific hook inside the hook script itself? This would just work after deployment of a hook script in /etc/pacman.d/hooks.d without any configuration file hassle. The Hooks would be self contained in files that pacman could source before doing anything. And if someone wants to know what a hook do and when it will be used there is only one place to look.
Marc
The one problem I see with that is that the actual script needs to be run. The post_install scripts etc, just source and run the script in a shell. This becomes more difficult if we have to keep information what files trigger the hooks to be run and when. Allan
Dan McGee wrote:
Let's get this in a wiki, I think that is a great idea to get it hashed out and make sure we aren't forgetting about certain scenarios.
Overall this seems like a workable approach.
I have made a wiki page for this: http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks I have tried to hash out what I think would be a workable config file. It is based on syntax used in pacman.conf so hopefully the parsing code can be reused. I think this is the most critical part of the proposal to get right so people should add any suggestions they have. Allan
participants (4)
-
Aaron Griffin
-
Allan McRae
-
Dan McGee
-
Marc - A. Dahlhaus [ Administration | Westermann GmbH ]