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

[Jeremy Katz]

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.

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

> 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