Axel Thimm wrote:
On Wed, Apr 26, 2006 at 03:11:02PM +0200, Tim Lauridsen wrote:
Axel Thimm wrote:
I not a kernel module packager, so i can't comment on the methology, but
from a user perspective the most important feature is automatic updating
of kernel-modules when new versions of the kernel is installed by yum,
this is working great with the madwifi,ntfs,nvidia drivers in the livna
fc5 repository. if kmdls can be used in the same way, then fine with me
for a users perspective.
There is a general issue with kernel modules and upgrading, not only
affecting the way ATrpms does it, but far more general. In a nutshell
you have a two-dimensional versioning which cannot be put into an
mathematically ordered relationship, no matter what you try (in fact
it can be proven mathematically for |Rx|R ;)
So for rpm's sake you need to neutralize one versioning and that leads
to the ugly-uname-r-in-package-name, or you break certain scenarios.
That OTOH makes yum/smart/apt properly upgrade within the kernel
(e.g. new kernel module for the same kernel), but not across
kernels. apt does have some special support to do that and yum and
smart could be taught, too.
Livna used to have the uname-r-in-package-name scenario, which worked
well because a kernel module for 2 different kernels was seen by yum as
two different packages, and this is desired functionality. They changed
now so that the package name is simply "kmod-ntfs" or similar, and thus
yum is now updating it when you get one for a new kernel, leaving the
old kernel without a module :(. I agree, if yum and smart were improved
to handle the two-dimensional versioning, that would make everything
much simpler.
[snip]
-Dan
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
