On Thu, 2006-06-22 at 18:55 -0700, Jane Dogalt wrote: > --- Jeremy Katz <katzj@xxxxxxxxxx> wrote: > > On Thu, 2006-06-22 at 15:21 -0700, Jane Dogalt wrote: > > > (How) Should one go about detecting in pre/post(/un) scripts in an rpm, > > whether > > > or not the rpm (de)installation is occurring on a live running system, or > > > within a chrooted (e.g. anaconda installer) based environment. > > > > This isn't something you should ever really need or want to do. > > Thats certainly a clear policy, which I like. I.e. that the assumption should > be a chrooted environment, and that anything which resembles futzing with a > live system is against policy (if I'm interpreting your statement correctly). Correct. spot -- want to add it to the guidelines? :-) > > > Specifically, lets pretend like qemu author decides to open source the > > kqemu > > > kernel module. > > > > > > It would seem you would want to modprobe the module during the post > > install, > > > and rmmod it during the postun(install). But you would only want to do > > these > > > things if the rpm was being installed on a live system. Not if you were > > doing > > > an rpm install in a chrooted environment (or whatever anaconda does during > > it's > > > normal install). > > > > No, you want to ensure that the module can get autoloaded when needed. > > This will be _far_ more robust than trying to do module > > installation/removal in scriptlets. > > So what about the case of an update to kernel module? Is it then the > responsibility of the installer (be it a script or a human) to rmmod the old > module, (or close the app which closes the device which(?) autounloads the > module), so that the next time the module is needed, the new module is > autoloaded? Realistically, new kernel modules are much like new kernels -- the only sane way to take advantage of them is by rebooting. Since by closing the app, you could be causing a user to lose work, etc. Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list