--- 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). > > > 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? -jdog > > > Now mind you, it's an entirely seperate question which I would like > answered, > > as to whether or not in the above case, there is a way to configure things > such > > that the kernel module gets autoloaded whenever qemu runs and tries to open > > /dev/kqemu. > > This can be done by dropping a file in /etc/modprobe.d containing > something like > alias char-major-x-y kqemu > > > But the general idea of not wanting to execute parts of your rpm > installscripts > > in the situation of chrooted, rather than live (un)installs, seems quite > > relevent for many situations. (and it seems like you would still probably > want > > to unload the old version of the module on uninstall if the autoloading > > mechanism didn't also auto-unload). > > You don't want this just like you don't want to run something like > 'killall gnome-calculator' on removal of gnome-utils. > > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-devel-list > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
