rpm packaging guideline question: differentiating between live/chroot installs?
Jane Dogalt
jdogalt at yahoo.com
Fri Jun 23 01:55:29 UTC 2006
--- 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).
>
> > 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 at redhat.com
> 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
More information about the fedora-devel-list
mailing list