Denis Leroy schrieb: > Jeremy Katz wrote: > >> But seriously, I am pretty vehemently opposed to differing databases for >> tracking installed software. If the benefits of recompiling modules >> automagically is big enough, then we should make sure that the _output_ >> of the recompilation is an rpm that we can install and track just like >> anything else. There's no reason that dkms couldn't do this. >> >> At the same time, I don't think that's the default behavior that we want >> for users who want extra kernel modules. Instead, they should be able >> to download, install and have them work just like the rest of the >> software that we ship. +1 to jeremy here > dkms is solving a problem that people have *now*; frequent 'yum update' > breakage (unless you use --skip-broken). I fail to follow you here, sorry. With the current kmod standard new kernels get installed even if the kmods are not available, so "--skip-broken" should not be needed. The kmods will get installed by yum when avilable. > Well, with a integrated Core+Extras build system, we could implement our > own automated kernel module rebuild system, a repo-level dkms if you > will. That was always the plan for the current kmod standard already. But nobody ever found time to drive it forward. Any volunteers? > [...] So that yum won't > let you update your kernel if that would mean losing wireless access, > for example. A yum plugin can afaics already handle that, but I never tried it. > We'll have to do this to resolve the firefox/galeon > breakages automatically also... That should hopefully become easier in the merged world with the new updates system. CU thl -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
