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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
