> I dealt with this for 1.2.10 another way everywhere I found that it > mattered. I'm guessing you did this patch for an earlier version and > ported it forward without checking what you needed, because:
1.2.9. > Remove this part (the linux/if.h change), and retry. It should still work. If I remove that whole patch, it is now fine. > That really only leaves the other question: can we, after these changes, > still build for other than just the most recent kernel version whose > source is installed? Yes... with a modification of the spec file. See earlier emailed reply. > Well, that and the inevitable person who I'm betting will grump that they > want the repository of modules and the "picker" script, but hopefully > they'll tell us why no other answer could work (if that's true) and not > just spew. Well, unless they're told to download the SRPM and build their own modules, it's likely to be a bit of a problem anyway. Any time a new kernel RPM is released, even if it's an ever-so slightly different version, they still have to be supplied with new kernel modules to match it. At the moment, you[*] have to build a complete new set of RPMs, to install; and while this RPM may include modules for all the older versions of kernel that you choose to support, it doesn't include modules for the version that gets released next week. On the other hand, you don't need a new userspace unless someone radically changes glibc, or unless there's a new version of OpenAFS. [*] I don't necessarily mean you personally. David _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
