[pacman-dev] Hooks in pacman
Hi, I added simple hooks support to pacman yesterday. Unfortunately I have not seen before that Sascha Kruse is already working on it. My concept is simpler and similar to the scriptlets. You might want to take a look at it even though. And another topic: I have seen that Allan is working on gpg-support. How far is this from deployment? Daniel
On 31/01/11 09:23, Daniel Mendler wrote:
And another topic: I have seen that Allan is working on gpg-support. How far is this from deployment?
Not all that far, but far enough that I very much doubt it will make a 3.5 release. Also, there has been no work on this by me (or anyone...) in the last few months. This is the current branch which I rebase on master ever so often: http://projects.archlinux.org/users/allan/pacman.git/log/?h=gpg I ran that branch for a while with a signed repo and it worked. There were obvious issues in terms of the output being awful and some bugs/missing features but it mostly works. This TODO is fairly up-to-date and complete: https://wiki.archlinux.org/index.php/User:Allan/Package_Signing I think that the pacman-key, makepkg, and repo-add TODOs could be knocked off by someone sitting down for a few hours and making a decent attack at them. Especially given some sort of patch is already available for most of it. The output and database update issues in pacman are probably the biggest blockers here. That is an area I would be very, very happy to receive patches for... Allan
2011/1/31 Daniel Mendler
Hi,
I added simple hooks support to pacman yesterday. Unfortunately I have not seen before that Sascha Kruse is already working on it. My concept is simpler and similar to the scriptlets. You might want to take a look at it even though.
My work up to this point was pretty much useless anyway. So I'll abandon my work for now and wait how this evolves. Greetings, Sascha
Hi
I added simple hooks support to pacman yesterday. Unfortunately I have not seen before that Sascha Kruse is already working on it. My concept is simpler and similar to the scriptlets. You might want to take a look at it even though.
My work up to this point was pretty much useless anyway. So I'll abandon my work for now and wait how this evolves.
It wasn't my intentions to stop your efforts here. I just didn't want to throw away my patches, so I sent them here. Because we both want hooks we should combine our work :) The problem is that the patches are a bit different. So at first we should discuss how hooks should look like. I like the concept with the shell-functions used in the install-scriptlets, so I used this scheme. Furthermore I think the hooks should be simple, this means only on a per-package (implemented in my patch) and per-transaction base. All other cases can be handled on the script-level (filtering for files, package names, etc). Activating a patch is as simple as copying a file to /etc/pacman.d/hooks. The per-transaction hooks are not yet in my patch, but this is easy to add (just add runhooks calls). The nice thing is that the per-transaction-hooks can replace the manual ldconfig runs for example. I am very interested in opinions of the development team! Daniel
2011/1/31 Daniel Mendler
Hi
I added simple hooks support to pacman yesterday. Unfortunately I have not seen before that Sascha Kruse is already working on it. My concept is simpler and similar to the scriptlets. You might want to take a look at it even though.
My work up to this point was pretty much useless anyway. So I'll abandon my work for now and wait how this evolves.
It wasn't my intentions to stop your efforts here. I just didn't want to throw away my patches, so I sent them here. Because we both want hooks we should combine our work :) The problem is that the patches are a bit different. So at first we should discuss how hooks should look like.
Yes, of course. I just tried to say that your patches look far more promising than the one I did. If there's something i can help with,i will.
I like the concept with the shell-functions used in the install-scriptlets, so I used this scheme. Furthermore I think the hooks should be simple, this means only on a per-package (implemented in my patch) and per-transaction base. All other cases can be handled on the script-level (filtering for files, package names, etc). Activating a patch is as simple as copying a file to /etc/pacman.d/hooks.
I agree with the shellfunctions. But I'm not sure wether the filtering for packages and files should be done within these scripts. The pro I see in putting this logic into the scripts is that there's no need for a configuration file for the hooks (given that we differentiate between transaction-based and package-based hooks by a prefix/suffix in their name or something similar). But on the other hand are the majority of usescases for hooks that come to my mind either depending on a certain package or file. Things like updating the font-cache or do custom stuff after a kernel upgrade.
I am very interested in opinions of the development team! Me too.
greetings, Sascha
Am Montag, den 31.01.2011, 02:07 +0100 schrieb Daniel Mendler:
Hi
Hello,
I added simple hooks support to pacman yesterday. Unfortunately I have not seen before that Sascha Kruse is already working on it. My concept is simpler and similar to the scriptlets. You might want to take a look at it even though.
My work up to this point was pretty much useless anyway. So I'll abandon my work for now and wait how this evolves.
It wasn't my intentions to stop your efforts here. I just didn't want to throw away my patches, so I sent them here. Because we both want hooks we should combine our work :) The problem is that the patches are a bit different. So at first we should discuss how hooks should look like.
I like the concept with the shell-functions used in the install-scriptlets, so I used this scheme. Furthermore I think the hooks should be simple, this means only on a per-package (implemented in my patch) and per-transaction base. All other cases can be handled on the script-level (filtering for files, package names, etc). Activating a patch is as simple as copying a file to /etc/pacman.d/hooks.
Did it mostly about the same way: I added a /usr/share/pacman/hook.d dir and installed hook scripts there. I added some helper functions to a /usr/share/pacman/hook.sh and sourced that file to the environment of the install scriptlets. I think i'll change this to simple "run-hook scriptname" and "trans-hook scriptname" bash scripts, because the including is not needed... I also added a /var/lib/packman/hook dir and touched empty files in there, that have the same name as the hook script to run for transaction hooks and a call to "/usr/share/pacman/hook.sh transaction" was added to /lib/libalpm/util.c after the callout to ldconfig which does a simple walk over the touched empty files in the /var/lib/packman/hook dir which fires up the corresponding hook and removes the empty file after that. It's based on pacman 3.3 and i have a forward port to 3.4 already on my agenda, if someone cares i can share the patches after that. IIRC there was a solution to run hooks on the basis of installed files (names or pathes) wanted / proposed last time we discussed triggers / hooks for pacman here. I'll try to dig up the thread in the archive...
The per-transaction hooks are not yet in my patch, but this is easy to add (just add runhooks calls). The nice thing is that the per-transaction-hooks can replace the manual ldconfig runs for example.
I am very interested in opinions of the development team!
Daniel
Marc
On Mon, Jan 31, 2011 at 4:45 AM, Marc - A. Dahlhaus
Am Montag, den 31.01.2011, 02:07 +0100 schrieb Daniel Mendler:
Hi
Hello,
I added simple hooks support to pacman yesterday. Unfortunately I have not seen before that Sascha Kruse is already working on it. My concept is simpler and similar to the scriptlets. You might want to take a look at it even though.
My work up to this point was pretty much useless anyway. So I'll abandon my work for now and wait how this evolves.
It wasn't my intentions to stop your efforts here. I just didn't want to throw away my patches, so I sent them here. Because we both want hooks we should combine our work :) The problem is that the patches are a bit different. So at first we should discuss how hooks should look like.
I like the concept with the shell-functions used in the install-scriptlets, so I used this scheme. Furthermore I think the hooks should be simple, this means only on a per-package (implemented in my patch) and per-transaction base. All other cases can be handled on the script-level (filtering for files, package names, etc). Activating a patch is as simple as copying a file to /etc/pacman.d/hooks.
Did it mostly about the same way:
I added a /usr/share/pacman/hook.d dir and installed hook scripts there.
I added some helper functions to a /usr/share/pacman/hook.sh and sourced that file to the environment of the install scriptlets. I think i'll change this to simple "run-hook scriptname" and "trans-hook scriptname" bash scripts, because the including is not needed...
I also added a /var/lib/packman/hook dir and touched empty files in there, that have the same name as the hook script to run for transaction hooks and a call to "/usr/share/pacman/hook.sh transaction" was added to /lib/libalpm/util.c after the callout to ldconfig which does a simple walk over the touched empty files in the /var/lib/packman/hook dir which fires up the corresponding hook and removes the empty file after that.
It's based on pacman 3.3 and i have a forward port to 3.4 already on my agenda, if someone cares i can share the patches after that.
IIRC there was a solution to run hooks on the basis of installed files (names or pathes) wanted / proposed last time we discussed triggers / hooks for pacman here. I'll try to dig up the thread in the archive...
The per-transaction hooks are not yet in my patch, but this is easy to add (just add runhooks calls). The nice thing is that the per-transaction-hooks can replace the manual ldconfig runs for example.
I am very interested in opinions of the development team!
So seems like many people have been hacking in private on this one. It is good that people are interested, bad that it is coming up now. We need to get a 3.5 out the door and right now my time is better spent looking at issues related to and getting ready for a release of that. These patches/work items will get a look in good time, but for now, they are simmering and waiting for 3.6.X development to start (updated today): https://wiki.archlinux.org/index.php/Pacman_Roadmap -Dan
participants (5)
-
Allan McRae
-
Dan McGee
-
Daniel Mendler
-
Marc - A. Dahlhaus
-
Sascha Kruse