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