On Mon, 7 Feb 2005 12:32:36 -0600, Justin Conover <justin.conover@xxxxxxxxx> wrote: > That makes sense now :D, the question would be were can I find the old > kernel You'll have to be lucky enough to find someone who is caching old rawhide packages. Rawhide is a rolling release... someone has to be caching the old kernels for you to be able to find one. > why isn't the package updated to include every kernel. You'd have to ask the maintainer of the gfs packagers about that. Frankly i think updating the gfs package to include multiple kernel versions worth of modules in the same package is the wrong way to go... you keep making the package bigger and bigger for each update kernel and forcing everyone to carry around the modules even if they dont have every kernel update installed. Doing that however would mean the buildsystem would need to rebuild the module for each released fedora kernel.. something i think would end up being too combersome. External repositories have mechanisms to try to address this problem without putting multiple versions in the same package. The are deeper questions that have to be answered about how the gfs modules are being packaged. Right now looking at the packaging i dont see anything in the packaging requires/provides that an instrumented build/release system could use to let the gfs maintainer be notified that the package was out of sync with the kernel. This means that the kernel packager and the gfs package need to be in personal contact everytime the kernel package needs updating. I think relying on personal communication between packagers is going to end up being less reliable than a scriptable test in the build/release system. Certaintly rawhide is its only special breed of breakage and watching something go out of sync in rawhide isn't uncommon. But I fear that the way gfs is being packaged right now in rawhide is going to lead directly to continual problems with kernel updates in fc4 for users using the gfs modules unless something is done to either tie in kernel version into the gfs package requirements or to make the build/release scripts aware that Provides: kernel-modules is a special case that must be watched for outside of the strict package dependancy self-consistency checks. Because right now the gfs package deps are completely self-consistent in the rawhide tree, even though its an unusable situation. -jef"the gfs-kernel module has forgotten to include the Provides: barrel-of- psychopathic-monkeys tag"spaleta