On Thu, Jun 22, 2006 at 03:21:27PM -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.
The idea of building in chroots is that it shouldn't be really
distinguishable from a live system. If a package does distinguish,
then the packaging (or the chroot) is broken.
It would seem you would want to modprobe the module during the post
install,
and rmmod it during the postun(install).
You wouldn't even want to do that on a live system. Who gurantees that
the kernel module being installed is for the running kernel? Or that
the user really wants it modprobed (the kernel modules that are part
of the kernel package aren't unconditionally modprobed, too).
On Thu, Jun 22, 2006 at 07:02:24PM -0700, Jane Dogalt wrote:
I forgot to add in first reply-
Does this mean that pre/post(un) scripts should be policywise-forbidden from
doing anything which directly or indirectly tries to touch /proc, which in a
chrooted environment, will not be mounted? I have this hunch that I've run
into rpms which do try to touch proc, though off the top of my head I can't
point any fingers.
You should be as non-invasive as possible. You shouldn't depend on
procfs/sysfs/udev and the like, and you shouldn't assume that the
kernel for which the kmdl is installed is currently running.
On Thu, Jun 22, 2006 at 06:55:29PM -0700, Jane Dogalt wrote:
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?
kernel modules should at the most adjust any relevant modprobe.conf
entries and in very rare cases touch the initrd (that's for kmdls
providing root fs access to SANs or RAIDs or similar kmdls needed
before /lib/modules can be accessed).
--
Axel.Thimm at
ATrpms.net