Max Vozeler wrote: > > > I'm doing something wrong: I need to install an alternative loop module > > > package that includes encryption, and which Provides: loop-modules, but > > > the original package is pulled in anyway. Any idea why this happens? > > > > Well we do support provides, but that doesn't mean it will do what you > > want when breaking a tie. :-) > > Hmm, good point. :) > > I've renamed the loop-AES module to loop-aes.o/ko in udebs, so it no > longer has a file conflict with the in-kernel version and the provides > becomes unnecessary. > > I'm curious though: If I include the loop-aes-$KVERS package in the > initrd, would there still be a tie situation, considering that a package > which provides loop-modules is already installed? That's what I tried > initially and made me believe provides were not working. I was thinking about this a bit more and it occurred to me that you may not be including the special header in your module udeb that the installer uses to know what kernel the modules work with. Do you have a XB-Kernel-Version: 2.4.27-2-386 header (or similar for the real kernel version)? > > Yes, you can hook in at either prebaseconfig time or you can add a > > base-installer hook script. Probably base-installer is the right place > > to add the hook. > > That would be: partman-crypto installs a script into > /usr/lib/post-base-installer.d/ and that script determines the target > kernel from debconf base-installer/kernel/image, right? base-installer/kernel/image is only a fallback, you'd probably have to look at base-installer/kernel/which-kernel. However, I don't envy you the task of converting a kernel image name back into something you can use to install your module. -- see shy jo
Attachment:
signature.asc
Description: Digital signature