Re: RFS: loop-aes (#111167)
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
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 :)
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 <firstname.lastname@example.org> http://hinterhof.net/~max
GnuPG B7CDA2DC : 308E 81E7 B979 63BC A0E6 ED88 9D5B D511 B7CD A2DC