[arch-dev-public] Hooks!
According to the news announcement, today is the day we can start using hooks! (as long as you live in the future like me - those of you in the past will need to catch up a day). I have started a wiki page to discuss which hooks to add [1]. So far this includes "update-desktop-database", "update-mime-database", and "info-install" hooks to be added. I also included a list of potential other hooks. I have no idea about these or how to create hooks for them, so it is up to other people. I'd like to get as many hooks as possible into our packages in one go and then create rebuild lists for them. This way, if a package can benefit from multiple hooks, it will only need rebuilt once. Please take a look at that page and add any hook that you think will be useful to your packages. I will dump the first three into packages in the next couple of days and make rebuild lists. These will not got to [staging]/[testing] as there is no harm having the hook do some duplicated effort until all the packages are rebuilt. Cheers, Allan [1] https://wiki.archlinux.org/index.php/DeveloperWiki:Pacman_Hooks
Allan McRae <allan@archlinux.org> on Sat, 2016/04/23 17:03:
According to the news announcement, today is the day we can start using hooks! (as long as you live in the future like me - those of you in the past will need to catch up a day).
I have started a wiki page to discuss which hooks to add [1]. [...]
[1] https://wiki.archlinux.org/index.php/DeveloperWiki:Pacman_Hooks
I can not edit the wiki page, so discussing here. How about a hook that rebuilds kernel initramfs images? Something like: [Trigger] Type = File Operation = Install Operation = Upgrade Target = boot/vmlinuz-linux Target = usr/lib/initcpio/* [Action] Description = Updating Arch Linux initramfs image When = PostTransaction Exec = /usr/bin/mkinitcpio -p linux -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
On Thu, Apr 28, 2016 at 11:14:36PM +0200, Christian Hesse wrote:
Allan McRae <allan@archlinux.org> on Sat, 2016/04/23 17:03:
According to the news announcement, today is the day we can start using hooks! (as long as you live in the future like me - those of you in the past will need to catch up a day).
I have started a wiki page to discuss which hooks to add [1]. [...]
[1] https://wiki.archlinux.org/index.php/DeveloperWiki:Pacman_Hooks
I can not edit the wiki page, so discussing here.
How about a hook that rebuilds kernel initramfs images? Something like:
[Trigger] Type = File Operation = Install Operation = Upgrade Target = boot/vmlinuz-linux Target = usr/lib/initcpio/*
[Action] Description = Updating Arch Linux initramfs image When = PostTransaction Exec = /usr/bin/mkinitcpio -p linux -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
It only benefits one package, so seems pointless to move it in hooks. If you have custom kernels installed you must run mkinitcpio anyway for all of them. -- Ike
On 29.04.2016 10:20, Ike Devolder wrote:
How about a hook that rebuilds kernel initramfs images? Something like:
It only benefits one package, so seems pointless to move it in hooks. If you have custom kernels installed you must run mkinitcpio anyway for all of them.
The current way of running mkinitcpio in the install scriptlet is broken. Some package that may be included in the initramfs might get updated after the script runs so their files in the initramfs may be the old versions. This has happened before and the only way to properly fix it is by using a hook to run the command at the very end of the update process. This is not pointless. Florian
Il giorno ven 29 apr 2016 alle ore 10:49 Florian Pritz <bluewind@xinu.at> ha scritto:
On 29.04.2016 10:20, Ike Devolder wrote:
How about a hook that rebuilds kernel initramfs images? Something like:
It only benefits one package, so seems pointless to move it in hooks. If you have custom kernels installed you must run mkinitcpio anyway for all of them.
The current way of running mkinitcpio in the install scriptlet is broken. Some package that may be included in the initramfs might get updated after the script runs so their files in the initramfs may be the old versions. This has happened before and the only way to properly fix it is by using a hook to run the command at the very end of the update process. This is not pointless.
I actually wanted to propose exactly this, so +1 from me. I was also wondering about a pacman hook ro run "systemctl daemon-reload" after systemd units installations/upgrades. This is something that was not done even in .install files but I don't know if there was a reason why. Others distros do this automatically, even the ones that do not have the bad habit of restarting the services for you without asking. Eg: I never had to do daemon-reload on CentOS 7. As far as I understand it shouldn't have any unintended side effects (and I certainly never experienced one). Thoughts?
Il giorno ven 29 apr 2016 alle ore 14:47 Massimiliano Torromeo < massimiliano.torromeo@gmail.com> ha scritto:
I was also wondering about a pacman hook ro run "systemctl daemon-reload" after systemd units installations/upgrades. This is something that was not done even in .install files but I don't know if there was a reason why.
I forgot to include the actual trigger. I've had this installed on some systems for a while: [Trigger] Operation = Install Operation = Upgrade Operation = Remove Type = File Target = usr/lib/systemd/system/* [Action] Description = Reload systemd unit files When = PostTransaction Exec = /usr/bin/systemctl --system daemon-reload Depends = systemd
Massimiliano Torromeo <massimiliano.torromeo@gmail.com> on Fri, 2016/04/29 12:47:
I was also wondering about a pacman hook ro run "systemctl daemon-reload" after systemd units installations/upgrades. This is something that was not done even in .install files but I don't know if there was a reason why.
Others distros do this automatically, even the ones that do not have the bad habit of restarting the services for you without asking. Eg: I never had to do daemon-reload on CentOS 7.
As far as I understand it shouldn't have any unintended side effects (and I certainly never experienced one). Thoughts?
Ah, and another one to reload udev rules: [Trigger] Operation = Install Operation = Upgrade Operation = Remove Type = File Target = usr/lib/udev/rules.d/* [Action] Description = Reload udev rule files When = PostTransaction Exec = /usr/bin/udevadm control --reload-rules Depends = systemd -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
On 05/02/16 07:20, Christian Hesse wrote:
Massimiliano Torromeo <massimiliano.torromeo@gmail.com> on Fri, 2016/04/29 12:47:
I was also wondering about a pacman hook ro run "systemctl daemon-reload" after systemd units installations/upgrades. This is something that was not done even in .install files but I don't know if there was a reason why.
Others distros do this automatically, even the ones that do not have the bad habit of restarting the services for you without asking. Eg: I never had to do daemon-reload on CentOS 7.
As far as I understand it shouldn't have any unintended side effects (and I certainly never experienced one). Thoughts?
Ah, and another one to reload udev rules:
[Trigger] Operation = Install Operation = Upgrade Operation = Remove Type = File Target = usr/lib/udev/rules.d/*
[Action] Description = Reload udev rule files When = PostTransaction Exec = /usr/bin/udevadm control --reload-rules Depends = systemd
--reload-rules (is keep but hidden for compatibility), renamed to --reload, in any case, rules are reloaded automagically (thanks to inotify).
Gerardo Exequiel Pozzi <vmlinuz386@gmail.com> on Mon, 2016/05/02 08:46:
On 05/02/16 07:20, Christian Hesse wrote:
Massimiliano Torromeo <massimiliano.torromeo@gmail.com> on Fri, 2016/04/29 12:47:
I was also wondering about a pacman hook ro run "systemctl daemon-reload" after systemd units installations/upgrades. This is something that was not done even in .install files but I don't know if there was a reason why.
Others distros do this automatically, even the ones that do not have the bad habit of restarting the services for you without asking. Eg: I never had to do daemon-reload on CentOS 7.
As far as I understand it shouldn't have any unintended side effects (and I certainly never experienced one). Thoughts?
Ah, and another one to reload udev rules:
[Trigger] Operation = Install Operation = Upgrade Operation = Remove Type = File Target = usr/lib/udev/rules.d/*
[Action] Description = Reload udev rule files When = PostTransaction Exec = /usr/bin/udevadm control --reload-rules Depends = systemd
--reload-rules (is keep but hidden for compatibility), renamed to --reload,
Ah, did not notice, yet.
in any case, rules are reloaded automagically (thanks to inotify).
Are you sure? Even attached strace to systemd-udevd and could not see any activity when changing files in /usr/lib/udev/rules.d/. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
On Mon, May 02, 2016 at 05:10:15PM +0200, Christian Hesse wrote:
Gerardo Exequiel Pozzi <vmlinuz386@gmail.com> on Mon, 2016/05/02 08:46:
On 05/02/16 07:20, Christian Hesse wrote:
Massimiliano Torromeo <massimiliano.torromeo@gmail.com> on Fri, 2016/04/29 12:47:
I was also wondering about a pacman hook ro run "systemctl daemon-reload" after systemd units installations/upgrades. This is something that was not done even in .install files but I don't know if there was a reason why.
Others distros do this automatically, even the ones that do not have the bad habit of restarting the services for you without asking. Eg: I never had to do daemon-reload on CentOS 7.
As far as I understand it shouldn't have any unintended side effects (and I certainly never experienced one). Thoughts?
Ah, and another one to reload udev rules:
[Trigger] Operation = Install Operation = Upgrade Operation = Remove Type = File Target = usr/lib/udev/rules.d/*
[Action] Description = Reload udev rule files When = PostTransaction Exec = /usr/bin/udevadm control --reload-rules Depends = systemd
--reload-rules (is keep but hidden for compatibility), renamed to --reload,
Ah, did not notice, yet.
in any case, rules are reloaded automagically (thanks to inotify).
Are you sure? Even attached strace to systemd-udevd and could not see any activity when changing files in /usr/lib/udev/rules.d/.
inotify hasn't been used in years. This is the current mechanism: https://github.com/systemd/systemd/blob/master/src/udev/udevd.c#L796 Rules won't be reloaded until there are events to process, and it's rate-limited to a max of once every 3 seconds.
On Mon, May 02, 2016 at 12:20:31PM +0200, Christian Hesse wrote:
Massimiliano Torromeo <massimiliano.torromeo@gmail.com> on Fri, 2016/04/29 12:47:
I was also wondering about a pacman hook ro run "systemctl daemon-reload" after systemd units installations/upgrades. This is something that was not done even in .install files but I don't know if there was a reason why.
Others distros do this automatically, even the ones that do not have the bad habit of restarting the services for you without asking. Eg: I never had to do daemon-reload on CentOS 7.
As far as I understand it shouldn't have any unintended side effects (and I certainly never experienced one). Thoughts?
Ah, and another one to reload udev rules:
[Trigger] Operation = Install Operation = Upgrade Operation = Remove Type = File Target = usr/lib/udev/rules.d/*
[Action] Description = Reload udev rule files When = PostTransaction Exec = /usr/bin/udevadm control --reload-rules
This doesn't (or shouldn't) do anything. udev periodically polls the timestamps on all of its rules.d directories (not just /usr/lib) and re-reads rules when it discovers they've changed.
Depends = systemd -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
On Fri, Apr 29, 2016 at 10:49:06AM +0200, Florian Pritz wrote:
On 29.04.2016 10:20, Ike Devolder wrote:
How about a hook that rebuilds kernel initramfs images? Something like:
It only benefits one package, so seems pointless to move it in hooks. If you have custom kernels installed you must run mkinitcpio anyway for all of them.
The current way of running mkinitcpio in the install scriptlet is broken. Some package that may be included in the initramfs might get updated after the script runs so their files in the initramfs may be the old versions. This has happened before and the only way to properly fix it is by using a hook to run the command at the very end of the update process. This is not pointless.
Florian
You are correct. So every kernel package must provide it's own hook just like every kernel package now has this in its install. -- Ike
Florian Pritz <bluewind@xinu.at> on Fri, 2016/04/29 10:49:
On 29.04.2016 10:20, Ike Devolder wrote:
How about a hook that rebuilds kernel initramfs images? Something like:
It only benefits one package, so seems pointless to move it in hooks. If you have custom kernels installed you must run mkinitcpio anyway for all of them.
The current way of running mkinitcpio in the install scriptlet is broken. Some package that may be included in the initramfs might get updated after the script runs so their files in the initramfs may be the old versions. This has happened before and the only way to properly fix it is by using a hook to run the command at the very end of the update process. This is not pointless.
Yup, that's the point. Every kernel package shout ships its own hook. This does not require and package rebuild, though. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
On 04/28/16 18:14, Christian Hesse wrote:
Allan McRae <allan@archlinux.org> on Sat, 2016/04/23 17:03:
According to the news announcement, today is the day we can start using hooks! (as long as you live in the future like me - those of you in the past will need to catch up a day).
I have started a wiki page to discuss which hooks to add [1]. [...]
[1] https://wiki.archlinux.org/index.php/DeveloperWiki:Pacman_Hooks
I can not edit the wiki page, so discussing here.
How about a hook that rebuilds kernel initramfs images? Something like:
[Trigger] Type = File Operation = Install Operation = Upgrade Target = boot/vmlinuz-linux Target = usr/lib/initcpio/*
[Action] Description = Updating Arch Linux initramfs image When = PostTransaction Exec = /usr/bin/mkinitcpio -p linux
+1 and there is a more important rebuild here, that I am doing in my installations, previously doing manually, since I am using systemd on initramfs, when systemd is update I need to rebuild initramfs (also for kmod just to be safe).
From: Christian Hesse <mail@eworm.de> Signed-off-by: Christian Hesse <mail@eworm.de> --- PKGBUILD | 5 +++++ linux-initramfs.hook | 11 +++++++++++ linux.install | 4 ---- 3 files changed, 16 insertions(+), 4 deletions(-) create mode 100644 linux-initramfs.hook diff --git a/PKGBUILD b/PKGBUILD index 1a40499..1ba2e60 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -20,6 +20,7 @@ source=("https://www.kernel.org/pub/linux/kernel/v4.x/${_srcname}.tar.xz" 'config' 'config.x86_64' # standard config files for mkinitcpio ramdisk 'linux.preset' + 'linux-initramfs.hook' 'change-default-console-loglevel.patch') sha256sums=('a93771cd5a8ad27798f22e9240538dfea48d3a2bf2a6a6ab415de3f02d25d866' @@ -27,6 +28,7 @@ sha256sums=('a93771cd5a8ad27798f22e9240538dfea48d3a2bf2a6a6ab415de3f02d25d866' 'b32a4fbd92cf561bca86bb65319a16be853fb8ea7bdd5f12974bd0d054d4c1f9' 'e91660a413baa66fb3269f03ceb85bda1df493b2fec404e9bb0269ad9a2d67a8' 'f0d90e756f14533ee67afda280500511a62465b4f76adcc5effa95a40045179c' + '2d4424928ae3c5f63ee618b4685580f4bd24faf1778553dbd961f85a88ea0910' '1256b241cd477b265a3c2d64bdc19ffe3c9bbcee82ea3994c590c2c76e767d99') validpgpkeys=( 'ABAF11C65A2970B130ABE3C479BE3E4300411886' # Linus Torvalds @@ -144,6 +146,9 @@ _package() { # add vmlinux install -D -m644 vmlinux "${pkgdir}/usr/lib/modules/${_kernver}/build/vmlinux" + + # install pacman hook + install -D -m644 "${srcdir}/linux-initramfs.hook" "${pkgdir}/usr/share/libalpm/hooks/linux-initramfs.hook" } _package-headers() { diff --git a/linux-initramfs.hook b/linux-initramfs.hook new file mode 100644 index 0000000..a32248e --- /dev/null +++ b/linux-initramfs.hook @@ -0,0 +1,11 @@ +[Trigger] +Type = File +Operation = Install +Operation = Upgrade +Target = boot/vmlinuz-linux +Target = usr/lib/initcpio/* + +[Action] +Description = Updating Arch Linux initramfs image +When = PostTransaction +Exec = /usr/bin/mkinitcpio -p linux diff --git a/linux.install b/linux.install index dd2fa5c..15dc8b6 100644 --- a/linux.install +++ b/linux.install @@ -8,8 +8,6 @@ post_install () { # updating module dependencies echo ">>> Updating module dependencies. Please wait ..." depmod ${KERNEL_VERSION} - echo ">>> Generating initial ramdisk, using mkinitcpio. Please wait..." - mkinitcpio -p linux${KERNEL_NAME} } post_upgrade() { @@ -20,8 +18,6 @@ post_upgrade() { # updating module dependencies echo ">>> Updating module dependencies. Please wait ..." depmod ${KERNEL_VERSION} - echo ">>> Generating initial ramdisk, using mkinitcpio. Please wait..." - mkinitcpio -p linux${KERNEL_NAME} if [ $(vercmp $2 3.13) -lt 0 ]; then echo ">>> WARNING: AT keyboard support is no longer built into the kernel." -- 2.8.2
[2016-05-18 13:55:40 +0200] Christian Hesse:
From: Christian Hesse <mail@eworm.de>
Signed-off-by: Christian Hesse <mail@eworm.de> --- PKGBUILD | 5 +++++ linux-initramfs.hook | 11 +++++++++++ linux.install | 4 ---- 3 files changed, 16 insertions(+), 4 deletions(-) create mode 100644 linux-initramfs.hook
Sorry but how is a hook better than the install scriptlet in this case? Are there other packages that need to run mkinitcpio? -- Gaetan
[2016-05-18 08:42:49 -1000] Gaetan Bisson:
[2016-05-18 13:55:40 +0200] Christian Hesse:
From: Christian Hesse <mail@eworm.de>
Signed-off-by: Christian Hesse <mail@eworm.de> --- PKGBUILD | 5 +++++ linux-initramfs.hook | 11 +++++++++++ linux.install | 4 ---- 3 files changed, 16 insertions(+), 4 deletions(-) create mode 100644 linux-initramfs.hook
Sorry but how is a hook better than the install scriptlet in this case? Are there other packages that need to run mkinitcpio?
Never mind. Seeing no commit message I was at loss but I was referred to an earlier discussion: https://lists.archlinux.org/pipermail/arch-dev-public/2016-May/027978.html -- Gaetan
On mer., 2016-05-18 at 13:55 +0200, Christian Hesse wrote:
From: Christian Hesse <mail@eworm.de>
# add vmlinux install -D -m644 vmlinux "${pkgdir}/usr/lib/modules/${_kernver}/build/vmlinux" + + # install pacman hook + install -D -m644 "${srcdir}/linux-initramfs.hook" "${pkgdir}/usr/share/libalpm/hooks/linux-initramfs.hook" }
Hello, I didn't pay much attention to this, but except dkms, hooks are not ordered. Could we use a prefix convention to order our hooks? It's usefull to build modules before building initramfs and eventually run grub update at the end. Something like: 50-XXX.hook - order doesn't matter 70-dkms.hook - ootm modules build 80-initramfs.hook - initramfs inclusion. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
Sébastien Luttringer <seblu@seblu.net> on Thu, 2016/05/19 01:20:
On mer., 2016-05-18 at 13:55 +0200, Christian Hesse wrote:
From: Christian Hesse <mail@eworm.de>
# add vmlinux install -D -m644 vmlinux "${pkgdir}/usr/lib/modules/${_kernver}/build/vmlinux" + + # install pacman hook + install -D -m644 "${srcdir}/linux-initramfs.hook" "${pkgdir}/usr/share/libalpm/hooks/linux-initramfs.hook" }
Hello,
I didn't pay much attention to this, but except dkms, hooks are not ordered.
Could we use a prefix convention to order our hooks? It's usefull to build modules before building initramfs and eventually run grub update at the end.
Something like:
50-XXX.hook - order doesn't matter 70-dkms.hook - ootm modules build 80-initramfs.hook - initramfs inclusion.
+1 from me. I was about to suggest the same. Actually we have zz-etckeeper-post-install.hook for package etckeeper to make it run last and catch all changes in /etc... A numeric prefix would be very useful. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
On jeu., 2016-04-28 at 23:14 +0200, Christian Hesse wrote:
Allan McRae <allan@archlinux.org> on Sat, 2016/04/23 17:03:
According to the news announcement, today is the day we can start using hooks! (as long as you live in the future like me - those of you in the past will need to catch up a day).
I have started a wiki page to discuss which hooks to add [1]. [...]
[1] https://wiki.archlinux.org/index.php/DeveloperWiki:Pacman_Hooks
I can not edit the wiki page, so discussing here.
How about a hook that rebuilds kernel initramfs images? Something like:
This is clearly better that the current situation, so +0.5! But as we are on the topic, could we consider directly moving to kernel-install to manage programs used to make the system able to boot (initramfs, bootladers) ? Initramfs rebuild logic is in a script in /usr/lib/kernel/install.d. Like grub or others bootloaders. I have a POC[1] here and I'm using it with good feedback since months. [1] https://git.archlinux.org/users/seblu/kernel-install-poc.git/ -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
Sébastien Luttringer <seblu@seblu.net> on Thu, 2016/05/19 01:35:
On jeu., 2016-04-28 at 23:14 +0200, Christian Hesse wrote:
Allan McRae <allan@archlinux.org> on Sat, 2016/04/23 17:03:
According to the news announcement, today is the day we can start using hooks! (as long as you live in the future like me - those of you in the past will need to catch up a day).
I have started a wiki page to discuss which hooks to add [1]. [...]
[1] https://wiki.archlinux.org/index.php/DeveloperWiki:Pacman_Hooks
I can not edit the wiki page, so discussing here.
How about a hook that rebuilds kernel initramfs images? Something like:
This is clearly better that the current situation, so +0.5!
But as we are on the topic, could we consider directly moving to kernel-install to manage programs used to make the system able to boot (initramfs, bootladers) ?
Initramfs rebuild logic is in a script in /usr/lib/kernel/install.d. Like grub or others bootloaders.
I have a POC[1] here and I'm using it with good feedback since months.
[1] https://git.archlinux.org/users/seblu/kernel-install-poc.git/
Just built and installed the packages. Your hooks' triggers have a target 'usr/lib/kernel/vmlinuz-*', which does not exist on my system. What changes are required to linux packages? Do you have linux packages that work with your hooks? And you should consider adding some more targets. For example updating packages 'systemd' or 'lvm2' should trigger an initramfs rebuild as well. That is why I added a target 'usr/lib/initcpio/*'. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
participants (9)
-
Allan McRae
-
Christian Hesse
-
Dave Reisner
-
Florian Pritz
-
Gaetan Bisson
-
Gerardo Exequiel Pozzi
-
Ike Devolder
-
Massimiliano Torromeo
-
Sébastien Luttringer