rpm packaging guideline question: differentiating between live/chroot installs?

[Jane Dogalt]

I couldn't find this issue addressed in the fedora pacakging guidelines page,
so I'll pose it here-

(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.

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).

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.

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).

Am I missing something?  Feel free to point me to a link to a prior thread
which hashes out this issue.

Thanks,

-jdog


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com