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

Axel Thimm Axel.Thimm at ATrpms.net
Fri Jun 23 11:19:04 UTC 2006


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060623/4641b6e9/attachment.sig>


More information about the fedora-devel-list mailing list