[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: loop-aes (#111167)



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 <max@hinterhof.net>           http://hinterhof.net/~max
GnuPG B7CDA2DC : 308E 81E7 B979 63BC A0E6  ED88 9D5B D511 B7CD A2DC



Reply to: