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
Attachment:
pgpCf54nIkvLi.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
