On Mon, 2006-08-14 at 16:16 -0400, seth vidal wrote: > On Mon, 2006-08-14 at 23:11 +0300, Panu Matilainen wrote: > > On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote: > > > > > Again, show me how kmdl scales. A university/enterprise environment is > > > not a 3rd party extras repository. > > > > I pointed out earlier in this thread that we've used a scheme similar to > > kmdl at work (speaking of thousands of systems here) rather successfully > > for several years. And like I stated previously as well, this is just > > for the record, I'm not arguing for either scheme. > > > > It's not kmdl or kmod that scales, it's the processes for releasing > > kernel modules and the depsolver+plugin to handle them which need to > > "scale": a plugin can be smart enough to skip the kernel update if no > > corresponding kernel module for the new version can be found, or abort > > the entire update. But you'll need plugins for both schemes to catch the > > situation where somehow a new kernel slipped out without having kernel > > modules for it available, otherwise you can end up with unbootable > > system. > > > > monkey-wrench question: > > what happens if both versions of a kernel module work on the available > kernel but work with different versions of the userland tools? S**t hits the fan, that's what happens... and neither scheme can protect against that. Similar things can happen with the main kernel itself.. you can update the kernel along with a userland (hal, udev or such) package which is incompatible with the running kernel yet rpm dependencies are satisfied. Runtime dependencies/provides would help a bit but then you'd have unresolvable deps on all the non-running kernels -> doesn't work either. - Panu - -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
