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

Jeremy Katz katzj at redhat.com
Fri Jun 23 14:19:05 UTC 2006


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




More information about the fedora-devel-list mailing list