At DevConf a few weeks ago, Stephen Gallagher and Will Woods gave a talk about removing rpm scriptlets. The recording hasn't been uploaded yet but the slides are available https://schd.ws/hosted_files/devconfcz2019/bc/scriptlet-reform-school-3.pdf The kernel uses a few scriptlets at the moment which will need to be cleaned up, most likely replaced with file triggers. We'll certainly be looking at this but if anyone is super excited about cleaning up packaging, this could be a good project (and much appreciated!)
Thanks, Laura
"LA" == Laura Abbott labbott@redhat.com writes:
LA> The kernel uses a few scriptlets at the moment which will need to be LA> cleaned up, most likely replaced with file triggers.
I have some experience converting things to file triggers had a quick look. It seems we have the following:
The main kernel package messes with /etc/sysconfig/kernel to change DEFAULTKERNEL in %post and has a %posttrans package to call /sbin/kernel-install.
The devel packages do some magic with hardlink calls (set up by %kernel_devel_post).
The modules and modules-extra packages have scriptlets to call depmod (set up by %kernel_modules_post and %kernel_modules_extra_post).
These are all buried in multiple layers of macros, so getting rid of any of this is probably a nice thing regardless of any other reasons scriptlets are problematic.
One fun thing is that I have no idea how file triggers interact with packages which are installed multiple times. If it works like I think it does, each kernel package (or maybe kernel-core package) would have something like:
%transfiletriggerin -n kernel-core -- /lib/modules/%{KVERREL}/ /sbin/depmod -a %{KVERREL}
%transfiletriggerpostun -n kernel-core -- /lib/modules/%{KVERREL}/ /sbin/depmod -a %{KVERREL}
The modules packages could then drop their scriptlets. These might need the variant magic or whatnot.
I don't really know about the hardlink calls; it would be trivial for something to call hardlink on /usr/src/kernels but optimizing that is more difficult.
I would think that the bootloader package or systemd-udev would be the proper place to put a trigger that calls kernel-install.
I don't really understand the modification of /etc/sysconfig/kernel.
In any case, it does seem that there's plenty of opportunity for useful cleanup here.
- J<
"JLT" == Jason L Tibbitts tibbs@math.uh.edu writes:
JLT> One fun thing is that I have no idea how file triggers interact JLT> with packages which are installed multiple times.
I now know: it works the way I hope it does, so the scriptlets I suggested for auto-running depmod should work properly. As a bonus, I think it would slightly simplify third party kernel module packages.
- J<
On Mon, Feb 18, 2019 at 06:46:01PM -0600, Jason L Tibbitts III wrote:
"LA" == Laura Abbott labbott@redhat.com writes:
LA> The kernel uses a few scriptlets at the moment which will need to be LA> cleaned up, most likely replaced with file triggers.
I have some experience converting things to file triggers had a quick look. It seems we have the following:
The main kernel package messes with /etc/sysconfig/kernel to change DEFAULTKERNEL in %post and has a %posttrans package to call /sbin/kernel-install.
The devel packages do some magic with hardlink calls (set up by %kernel_devel_post).
The modules and modules-extra packages have scriptlets to call depmod (set up by %kernel_modules_post and %kernel_modules_extra_post).
These are all buried in multiple layers of macros, so getting rid of any of this is probably a nice thing regardless of any other reasons scriptlets are problematic.
One fun thing is that I have no idea how file triggers interact with packages which are installed multiple times. If it works like I think it does, each kernel package (or maybe kernel-core package) would have something like:
%transfiletriggerin -n kernel-core -- /lib/modules/%{KVERREL}/ /sbin/depmod -a %{KVERREL}
%transfiletriggerpostun -n kernel-core -- /lib/modules/%{KVERREL}/ /sbin/depmod -a %{KVERREL}
kernel-install already calls depmod (from /usr/lib/kernel/install.d/50-depmod.install). As long as kernel-install is called for the kernel, those scriptlets/transfiletriggers are not necessary.
The modules packages could then drop their scriptlets. These might need the variant magic or whatnot.
I don't really know about the hardlink calls; it would be trivial for something to call hardlink on /usr/src/kernels but optimizing that is more difficult.
I would think that the bootloader package or systemd-udev would be the proper place to put a trigger that calls kernel-install.
systemd-udev contains kernel-install, so any transfiletriggers that calls it should live there.
I don't really understand the modification of /etc/sysconfig/kernel.
/etc/sysconfig/kernel is used by grubby's new-kernel-pkg for something, I think. Javier Canillas and Peter Jones in CC.
In any case, it does seem that there's plenty of opportunity for useful cleanup here.
Totally agreed. This doesn't have to happen at at once, it'd probably be even better to chip at it away a piece at a time.
Zbyszek
"ZJ" == Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl writes:
ZJ> kernel-install already calls depmod (from ZJ> /usr/lib/kernel/install.d/50-depmod.install).
I'm not sure that's sufficient. Packages can install modules at any time and I believe depmod needs to be called when this happens. Thus the kernel packages need a file trigger on the /lib/modules/XXX directory that they own. Either that or something at a different level needs to be responsible for calling depmod for things installed under /lib/module.
The depmod call in kernel-install is really somewhat redundant, though I don't think calling depmod is particularly slow so it probably doesn't much matter.
- J<
kernel@lists.fedoraproject.org
-
Jason L Tibbitts III -
Laura Abbott -
Zbigniew Jędrzejewski-Szmek