Jack Neely schrieb:
The code is in yum-utils CVS and will be in that package the next
time
its released.
thx for your work!
I support kernel module upgrading (where an older module
needs to be removed to avoid file conflicts) and pinning the kernel
until the kernel modules the system uses are available for the new
kernel.
Hmmm, pinning sounds nice, but should we enable it as default? The
questions afaics simply is:
Whats more important? Running the latest kernel where all known security
problems are fixed or running a kernel where all modules are present?
I'd prefer the solution where all security problems are fixed, even if I
lose functionality. I know, that not ideal in every situation, but
security IMHO is more important so it should be the default. If users
modify it than it's not our fault.
What functionality from the plugin would folks like to see in FC6 so
that we could be closer to having kernel modules in extras?
There is one oddity currently discussed on fedora-packaging. Maybe you
can fix it in your plugin easily:
Situation:
$ rpm -q kernel
kernel-2.6.17-1.2145_FC5
kernel-2.6.17-1.2157_FC5
kernel-smp-2.6.17-1.2157_FC5
$ rpm -qa kmod-ntfs*
kmod-ntfs-2.1.27-1.2.6.17_1.2145_FC5
kmod-ntfs-2.1.27-1.2.6.17_1.2157_FC5
kmod-ntfs-smp-2.1.27-1.2.6.17_1.2157_FC5
kmod-ntfs{,-smp,xen0,...}-2.1.27-2.2.6.17_1.2157_FC5 show up in the repo
and user runs yum update. After that:
$ rpm -qa kmod-ntfs*
kmod-ntfs-2.1.27-2.2.6.17_1.2157_FC5
kmod-ntfs-smp-2.1.27-2.2.6.17_1.2157_FC5
e.g. kmod-ntfs-2.1.27-1.2.6.17_1.2145_FC5 was removed. Can that be
circumvented?
BTW, does a simple "yum install kmod-foo" now install modules for all
kernel-variants taht are present? E.g. I'd like to see this:
$ rpm -q kernel
kernel-2.6.17-1.2157_FC5
kernel-smp-2.6.17-1.2157_FC5
$ yum install kmod-foo
[...]
$ rpm -qa kmod-foo*
kmod-foo-2.1.27-1.2.6.17_1.2157_FC5
kmod-foo-smp-2.1.27-1.2.6.17_1.2157_FC5
CU
thl