Jeremy Katz wrote:
On Mon, 2007-01-22 at 17:10 +0100, Matthias Saou wrote:
Jeremy Katz wrote :
Heck, why don't we also stop packaging perl modules as RPMs. I mean,
there's CPAN, right? And there's now the cheeseshop + setuptools for
python.
Well, we just don't push out a new perl version to the released updates
every few weeks :-)
If the Fedora kernel never got updated, and only got bugfixes, then
maybe kernel module packages would work well enough with weak symbols
and such... but it would mean just too much wasted effort.
If only upstream would work like that :-)
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.
dkms is solving a problem that people have *now*; frequent 'yum update'
breakage (unless you use --skip-broken).
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 has the advantage of staying "pure-RPM" and also guarantees
that the module compiles with the new kernel update. So that yum won't
let you update your kernel if that would mean losing wireless access,
for example. We'll have to do this to resolve the firefox/galeon
breakages automatically also...
-denis
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
