I've been experimenting with the RHEL5 yum repository, and came across the following unfortunatel situation:
If you attempt to install openafs-client, and a kmod package does not exist for your kernel version, it will attempt to install a kernel for which it has a supported kmod. This is a fine assumption if your current kernel is older than the one the kmod requires, but not if it's newer. Attempting to install openafs-client on a machine running 2.6.18-8.1.15 fails, since yum won't let you install an older kernel. --- [EMAIL PROTECTED] jdreed]# yum install openafs-client *snip* ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: openafs-client x86_64 1.4.5-el5.1 openafs 613 k Removing: kernel x86_64 2.6.18-8.el5 installed 72 M Installing for dependencies: kernel x86_64 2.6.18-8.1.14.el5 rhel-x86_64-client-5 14 M kmod-openafs x86_64 1.4.5-1.2.6.18_8.1.14.el5 openafs 270 k *snip* Transaction Check Error: package kernel-2.6.18-8.1.15.el5 (which is newer than kernel-2.6.18-8.1.14.el5) is already installed --- I realize that the workaround is probably to install openafs-kernel-source, which seems to satisfy the requirements of openafs-client, but is it necessary for the kmod packages to require a kernel version? While it's true that the kmod won't work in other kernel versions, since it installs in a separate directory, it seems like it would be better to drop the explicit requirement to avoid failure modes like this one. Presumably there will always be some skew between when Redhat releases a new kernel and when openafs releases the kmod for it, but I can also see the case for enforcing requirements to prevent users from thinking they have installed a working kmod when they haven't. -Jon _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
