On Wed, 2006-08-16 at 19:29 +0200, Axel Thimm wrote: > Just to make it clear the actual changes wrt kmod are: > > o use kabi-version instead of uname-r > o disambiguate the file paths of the modules, so modules of different > module versions are coinstallable *for the same kernel/kabi*!!! > > In fact this scheme is far more broken than the old kmod scheme: > > o The 'only-last-kernel-supported' simply becomes > 'only-last-kabi-supported'. For Fedora it's the same anyway. > So you still have issues with > - no (security) updates for old kernels (or kabis) Okay. I haven't seen anything to contradict this yet, only a conflict over whether this is a problem or not. (If I'm wrong, somebody point me to the archives or restate the rebuttal) Even if kmdls were accepted, are we planning on having the buildsystem build for multiple kernels? > - old kernels/kabis can get their module nuked or effectively > disabled. > How? Will not get overwritten (which is how I think the term "nuked" has been used in this thread.) Effectively disabled: What leads you to that conclusion? > o Currently there is a file conflicst guard of not having different > modules for the same kernel coinstalled. The disambiguation in the > file path lifts this safety pin and suddenly we can end up with > several different module versions for the same kernel!!! > But they are not being used. If we treat the kernel modules the same as the kernel itself, then this is expected. It could even be considered desirable: Upgraded modules doesn't work? Re-symlink the old module and you're set. > The kabi stuff is for using modules built for different kernels/kabis, > not to have several modules of different versions coinstalled for the > same kernel/kabi. We certainly want to have foo-2 kernel modules for > kernel/kabi X to replace foo-1 for the same kernel/kabi and not > coinstall. > I don't think that's a given. If I installed a new module from source, I'd like the option to coinstall with whatever I had on the system before so I could recover the system if I had to. With packaging it's not as important because I could download the old package and reinstall. Although I think we are removing old packages from the repository. What if the module from January is the last one that worked for me and the next ten do not? (Of course, I may be stuck with an old kernel then, as well... Like I said, I'm not sold either way.) Also, if I'm rebuilding my kernels from fedora source with some local changes to the kernel.config, a plan that places all external modules into a common directory and then makes symlinks to the relative kernel directories would help me use prebuilt kernel modules. > And please stop throwing new kernel modules schemes to me :=) The problem is we're here debating 1) Can kmods be saved and 2) if they can't be saved, do we want kmdls to replace them verbatim? So as you throw problems at the new proposals, people are going to update the proposals to try to fix those problems. In the end we'll all agree that there is an actual problem that no amount of fixing can actually solve, or we'll look at the two proposals and say this pile of hacks is less appealing to me than this one for [insert arbitrary reason here]. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
