On Mon, Feb 18, 2008 at 12:35:19PM -0500, Don Zickus wrote: > On Sat, Feb 16, 2008 at 09:53:26AM -0600, Matt Domsch wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=433121 > > > > DKMS would like to have the opportunity to run it's > > auto-rebuilder/installer after a new kernel RPM has been installed, > > without having to wait for a system restart to run it. Likewise, when > > a kernel RPM is removed, it would like to be able to run to remove > > modules managed by it. > > > > Debian kernels intentionally run scripts located in > > /etc/kernel/postinst.d/ following new kernel package installation, > > /etc/kernel/prerm.d/ before kernel package removal. DKMS drops a > > script into these directories, to perform the appropriate actions. > > > > I want Fedora and RHEL kernels to do likewise. Patch attached. > > This patch implements the same interface as that used for Debian and > > Ubuntu kernels. The scripts are invoked with $1 = kernel version, and > > $2 = path to vmlinuz file. (DKMS doesn't need $2, but I'm keeping the > > interface the same to match so people can reuse their scriptlets.) > > I argued against this idea in RHEL because I believe blindly running > random scripts in a directory is an unsafe thing to do (despite its best > intentions it can still be abused). > > Also from a support perspective, it becomes more complicated to support > kernel installs when random user scripts can cause unknown behaviour. This has been the argument against DKMS for 5 years now. However, in those 5 years, how many support calls has Red Hat taken where a DKMS-ified driver turned out to be the problem? Where it wasn't obvious what was happening? 'dkms status' is even part of sysreport, and has been for at least 3 years. I'd accept a change to new-kernel-package rpmposttrans() that invokes the DKMS script directly, as opposed to looping through a plug-in directory, if that makes people feel any better. I suspect it doesn't though. Waiting on a higher-level tool to assist the support guys ask for 'dkms status' info may be appropriate for RHEL, but not for Fedora. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list
