On Thu, 2006-06-22 at 18:55 -0700, Jane Dogalt wrote:
--- Jeremy Katz <katzj(a)redhat.com> 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