On Tue, Aug 18, 2015 at 06:28:53PM +0100, Ned Slider wrote: > Lets look at an example. Every couple weeks RH release a kernel update > but I can't update because my matching kmod-openafs isn't available yet. > First I have to wait for CentOS to rebuild it and release the kernel > update (lag). Then I have to wait for the SIG to rebuild their > kmod-openafs against the newly built CentOS kernel (more lag). If I > accidentally update my kernel and reboot - poof, I'm burned. Every time, > guaranteed. If I don't update my kernel then compliance are on my case > because I'm vulnerable to the latest CVE. > > Personally, if I'm gonna get burned I'd rather be burned every 9 months > that every single time upstream releases a new kernel update. So, in these scenarios: 1.) Per-kernel kmod package: You can't update your kernel to the latest because kmod-openafs prevents it. The only kernels installed are ones that work with AFS. 2.) Per-point-release kmod package: You get a new kernel, reboot, and afs fails to mount because the AFS filesystem fails. You have no $HOME, no apps, and unless you're an openafs developer, you have no idea why it didn't load. You have to build a new kmod, or bug someone to do it for you. The only way this doesn't happen is if a CentOS volunteer happens to be fast enough at testing to know to rebuild the kmod package before you happen to see the new kernel on the mirrors. What is the best user scenario? I'm pretty sure that the commercial support for AFS builds a kmod for every kernel. I was only trying to get a SPEC file that worked well with koji, which is largely working, except for things I've already mentioned. -- Jonathan Billings <billings at negate.org>