Re: [pacman-dev] Hooks for pacman
Am Samstag, den 24.01.2009, 00:52 +1000 schrieb Allan McRae:
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
The point was that this way you can install new hooks with packages and they would just work without any configuration file fiddling. It would be cleaner for a packager in my opinion. Marc
Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
Am Samstag, den 24.01.2009, 00:52 +1000 schrieb Allan McRae:
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.
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.
The point was that this way you can install new hooks with packages and they would just work without any configuration file fiddling. It would be cleaner for a packager in my opinion.
I understood you point. My point is that each hook need to provide the following information: 1. when to run it (per file or transaction) 2. what files trigger it running 3. a script that can be sourced and run by the shell. It is _a lot_ easier if 1 and 2 are separate from 3. If you can propose a clean way to have them all together, then we will be happy to consider it. Allan
On Fri, Jan 23, 2009 at 9:38 AM, Allan McRae <allan@archlinux.org> wrote:
Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
Am Samstag, den 24.01.2009, 00:52 +1000 schrieb Allan McRae:
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.
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.
The point was that this way you can install new hooks with packages and they would just work without any configuration file fiddling. It would be cleaner for a packager in my opinion.
I understood you point. My point is that each hook need to provide the following information:
1. when to run it (per file or transaction) 2. what files trigger it running 3. a script that can be sourced and run by the shell.
It is _a lot_ easier if 1 and 2 are separate from 3. If you can propose a clean way to have them all together, then we will be happy to consider it.
Hmmm #myhook RUN=PerFile PATTERN=/usr/share/info/* ##### run () { ... } We could do something nasty where pacman parses the file, ignores all lines that it doesn't match to '^RUN' or '^PATTERN', and possibly end parsing early at some token (the ##### above) Still, it's a little nasty. I almost prefer the manual config file editing for a few reasons: It doesn't force the user to use these hooks. *I* should have to turn on the install-info hook myself.
On Fri, Jan 23, 2009 at 11:56 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Jan 23, 2009 at 9:38 AM, Allan McRae <allan@archlinux.org> wrote:
Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
Am Samstag, den 24.01.2009, 00:52 +1000 schrieb Allan McRae:
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.
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.
The point was that this way you can install new hooks with packages and they would just work without any configuration file fiddling. It would be cleaner for a packager in my opinion.
I understood you point. My point is that each hook need to provide the following information:
1. when to run it (per file or transaction) 2. what files trigger it running 3. a script that can be sourced and run by the shell.
It is _a lot_ easier if 1 and 2 are separate from 3. If you can propose a clean way to have them all together, then we will be happy to consider it.
Hmmm
#myhook RUN=PerFile PATTERN=/usr/share/info/* ##### run () { ... }
We could do something nasty where pacman parses the file, ignores all lines that it doesn't match to '^RUN' or '^PATTERN', and possibly end parsing early at some token (the ##### above)
Still, it's a little nasty. I almost prefer the manual config file editing for a few reasons: It doesn't force the user to use these hooks. *I* should have to turn on the install-info hook myself.
One thing that just came to mind (emailing it before I forget): We need to differentiate between additions and removals for the "per trans" hooks somehow. Take, for instance, info files. On add: install-info /path/to/file On remove: install-info --delete /path/to/file The per-trans hook needs to do BOTH steps in the case of an upgrade (a remove then an add). Right? Or do info files work fine in this case?
Aaron Griffin wrote:
On Fri, Jan 23, 2009 at 11:56 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Jan 23, 2009 at 9:38 AM, Allan McRae <allan@archlinux.org> wrote:
Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
Am Samstag, den 24.01.2009, 00:52 +1000 schrieb Allan McRae:
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.
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.
The point was that this way you can install new hooks with packages and they would just work without any configuration file fiddling. It would be cleaner for a packager in my opinion.
I understood you point. My point is that each hook need to provide the following information:
1. when to run it (per file or transaction) 2. what files trigger it running 3. a script that can be sourced and run by the shell.
It is _a lot_ easier if 1 and 2 are separate from 3. If you can propose a clean way to have them all together, then we will be happy to consider it.
Hmmm
#myhook RUN=PerFile PATTERN=/usr/share/info/* ##### run () { ... }
We could do something nasty where pacman parses the file, ignores all lines that it doesn't match to '^RUN' or '^PATTERN', and possibly end parsing early at some token (the ##### above)
Still, it's a little nasty. I almost prefer the manual config file editing for a few reasons: It doesn't force the user to use these hooks. *I* should have to turn on the install-info hook myself.
One thing that just came to mind (emailing it before I forget):
We need to differentiate between additions and removals for the "per trans" hooks somehow.
Take, for instance, info files.
On add: install-info /path/to/file On remove: install-info --delete /path/to/file
The per-trans hook needs to do BOTH steps in the case of an upgrade (a remove then an add). Right? Or do info files work fine in this case?
I count install-info stuff as a "per file" hook rather than a per-trans hook because you need to pass a file name. Per trans hooks would be mainly for updating font/desktop/icon databases where filenames are not needed. While I cannot think of any need for a pre-transaction hook, that does not mean someone won't and I am willing to lean on the side of generality for this. Allan
On Tue, Jan 27, 2009 at 7:57 PM, Allan McRae <allan@archlinux.org> wrote:
Aaron Griffin wrote:
On Fri, Jan 23, 2009 at 11:56 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Jan 23, 2009 at 9:38 AM, Allan McRae <allan@archlinux.org> wrote:
Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
Am Samstag, den 24.01.2009, 00:52 +1000 schrieb Allan McRae:
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. > >
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.
The point was that this way you can install new hooks with packages and they would just work without any configuration file fiddling. It would be cleaner for a packager in my opinion.
I understood you point. My point is that each hook need to provide the following information:
1. when to run it (per file or transaction) 2. what files trigger it running 3. a script that can be sourced and run by the shell.
It is _a lot_ easier if 1 and 2 are separate from 3. If you can propose a clean way to have them all together, then we will be happy to consider it.
Hmmm
#myhook RUN=PerFile PATTERN=/usr/share/info/* ##### run () { ... }
We could do something nasty where pacman parses the file, ignores all lines that it doesn't match to '^RUN' or '^PATTERN', and possibly end parsing early at some token (the ##### above)
Still, it's a little nasty. I almost prefer the manual config file editing for a few reasons: It doesn't force the user to use these hooks. *I* should have to turn on the install-info hook myself.
One thing that just came to mind (emailing it before I forget):
We need to differentiate between additions and removals for the "per trans" hooks somehow.
Take, for instance, info files.
On add: install-info /path/to/file On remove: install-info --delete /path/to/file
The per-trans hook needs to do BOTH steps in the case of an upgrade (a remove then an add). Right? Or do info files work fine in this case?
I count install-info stuff as a "per file" hook rather than a per-trans hook because you need to pass a file name. Per trans hooks would be mainly for updating font/desktop/icon databases where filenames are not needed. While I cannot think of any need for a pre-transaction hook, that does not mean someone won't and I am willing to lean on the side of generality for this.
Allan
How will you handle things like gconfpkg (/usr/share/pacman/proto-gnome.install) ? You need to pass the pkgname. Will there be a "per package" hook? Or will you just use the "per file" hook with the pkgname as argument. Just wanted to bring that out.
Eric Bélanger wrote:
On Tue, Jan 27, 2009 at 7:57 PM, Allan McRae <allan@archlinux.org> wrote:
Aaron Griffin wrote:
On Fri, Jan 23, 2009 at 11:56 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Jan 23, 2009 at 9:38 AM, Allan McRae <allan@archlinux.org> wrote:
Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
Am Samstag, den 24.01.2009, 00:52 +1000 schrieb Allan McRae:
> 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. >> >> >> > 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. > > > The point was that this way you can install new hooks with packages and they would just work without any configuration file fiddling. It would be cleaner for a packager in my opinion.
I understood you point. My point is that each hook need to provide the following information:
1. when to run it (per file or transaction) 2. what files trigger it running 3. a script that can be sourced and run by the shell.
It is _a lot_ easier if 1 and 2 are separate from 3. If you can propose a clean way to have them all together, then we will be happy to consider it.
Hmmm
#myhook RUN=PerFile PATTERN=/usr/share/info/* ##### run () { ... }
We could do something nasty where pacman parses the file, ignores all lines that it doesn't match to '^RUN' or '^PATTERN', and possibly end parsing early at some token (the ##### above)
Still, it's a little nasty. I almost prefer the manual config file editing for a few reasons: It doesn't force the user to use these hooks. *I* should have to turn on the install-info hook myself.
One thing that just came to mind (emailing it before I forget):
We need to differentiate between additions and removals for the "per trans" hooks somehow.
Take, for instance, info files.
On add: install-info /path/to/file On remove: install-info --delete /path/to/file
The per-trans hook needs to do BOTH steps in the case of an upgrade (a remove then an add). Right? Or do info files work fine in this case?
I count install-info stuff as a "per file" hook rather than a per-trans hook because you need to pass a file name. Per trans hooks would be mainly for updating font/desktop/icon databases where filenames are not needed. While I cannot think of any need for a pre-transaction hook, that does not mean someone won't and I am willing to lean on the side of generality for this.
Allan
How will you handle things like gconfpkg (/usr/share/pacman/proto-gnome.install) ? You need to pass the pkgname. Will there be a "per package" hook? Or will you just use the "per file" hook with the pkgname as argument. Just wanted to bring that out.
The file that would set off the gconfpkg hook would be like /usr/share/gconf/schemas/pkgname.schemas. So the script will be passed the filename and can extract the pkgname from that reasonably easily. Allan
participants (4)
-
Aaron Griffin
-
Allan McRae
-
Eric Bélanger
-
Marc - A. Dahlhaus [ Administration | Westermann GmbH ]