Hi Eduard, thanks for suggesting module-assistant, I read up on it and re-wrote debian/rules in loop-aes-source accordingly. This should address most of the issues, details below. The modass override files are included in loop-aes-utils 2.11z-5.
What's not ready: - README.Debian hasnt been updated to reflect the switch to module-assistant - loop-aes-ciphers-source hasnt been converted to module-assistant - the new binary module packages are not uploaded yet On Wed, Nov 26, 2003 at 09:58:28AM +0100, Eduard Bloch wrote: > > Hm, as said before, look at the examples I mentioned: > > - you do not provide a source tarball in /usr/src called after the > common name conventions (pkg-name without trailing -source) It does now. > - your packages do DEPEND on the kernel-image-foo but it is not > guaranteed that a make-kpkg'ed kernel is used. In fact, you > completely rely on what the macros of dh_make detect but this > calculations are written for detecting some random kernel, they do > NOT guarantee that a kernel-image-... package is used. In fact, there > are insufficient to rely on anything (IMHO), that is why there is the > module-assistant package Good point. After some attempts at fixing it with more scripting, I decided to use module-assistant after all. The resulting packages only recommend the kernel-image. > - I guess you did NEVER install the created packages for the kernels > you build them for. It tries to overwrite loop.o from the main kernel > as well as modules.dep and a bunch of other files. WTF? Same thing > with the -ciphers package. You maybe want to use dpkg-divert for > loop.o and not put any of the depmod products into the package but > run depmod -a from the package. Opps :) I did check some of them actually. The error slipped me as depmod was only run if running kernel != built kernel. Anyways, the depmod invocation during build is gone in favour of one in postinst. About the overwriting of loop.o, I actually thought a dpkg-divert wasnt necessary as loop-aes installs the module in /lib/modules/$KVERS/block rather than /lib/modules/$KVERS/kernel/drivers/block where the original module lives. (Which also causes it to take precendece with modprobe, but that may have ugly side-effects that I'm not aware of) So the question is, does it still happen with loop-aes-source 1.7e-13 and if yes, where does it try to install loop.o to on your machine? Is a dpkg-divert for the module necessary after all? > - you recommend to run the binary-modules rule but this rule does NOT > run clean before _and_ after the build process. Expect trouble when > kernel source or compiler change inexpectedly Fixed for binary-modules. What about other targets, does this apply too? > - your rules files still ignore KPKG_DEST_DIR (as said, > module-assistant's includes will handle it or rip code from > alsa-source) Resolved with module-assistant. Soo.. while I am working on loop-aes-ciphers-source, please tell me about any oddities you find. You have been very helpful so far, thanks a lot for your time :) Greets Max btw, my solution to loop-aes's need of a full kernel source was to always pass -k /path/to/src to module-assistant. Is there another way to make m-a aware of that fact? -- Max Vozeler <[EMAIL PROTECTED]> http://hinterhof.net/~max GnuPG B7CDA2DC : 308E 81E7 B979 63BC A0E6 ED88 9D5B D511 B7CD A2DC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
