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

Re: Thank you so much for breaking d-i!



On 15.07.2012 17:37, Marco d'Itri wrote:
> On Jul 15, Bastian Blank <waldi@debian.org> wrote:
> 
>> Can you provide the number of the bugreport requesting removal of the
>> udeb? However, why is there a udeb called libkmod2-udeb then?
> It was discussed on IRC, I think with the busybox maintainer.

Well, if think it really was me (unless you mean some other
discussion which I don't know about), and yes we ta I told
you about busybox and modprobe (and other utils from m-i-t
or kmod family).  It was after you told me that m-i-t is
going to be replaced with kmod.

There are two "discussions", or talks, were happining almost
at once.

One was about d-i, -- I notified #d-boot that busybox is now
able to replace m-i-t.udeb as it has the same functionality
(this is when you said that m-i-t is going to be replaced),
and suggested not to enable this functionality in busybox (but
it has been enabled already).

And another - I told you that in INITRAMFS, ie, in regular
busybox, modprobe from busybox is used, not from m-i-t or
kmod package.  This is because busybox includes modprobe&Co
in its regular build too (due to too high demand), and becase
this build is built with FEATURE_PREFER_APPLETS enabled,
which means that when busybox wants to exec something, it
searches its applet of the same name first, and goes to $PATH
next (why this option is enabled is another question/topic).

In both cases, no one actually _disabled_ usage of kmod or
m-i-t: in particular, in d-i, m-i-t is still used, and in
initramfs case, the binaries will be put into initramfs even
it they wont be used.

I can only guess there was some misunderstanding between us
happened.  Or maybe I wasn't clear, or even wrong - sometimes
I think "d-i" but say "initramfs" (as both environments are
sort of "minimal," "pre-boot" (or even pre-install) and thus
very different from regular installed system).  I can try to
find this discussion in my irclogs, to see whenever I really
said about d-i or initramfs (to mean initramfs ofcourse).

Unfortunately, whomever was not writing or reading wrongly
does not fix the breakage now... :(

Note: in order to enable busybox modprobe&Co in d-i, the ONLY
thing needed is to _remove_ any alternatives (m-i-t or kmod),
because when d-i is built, it runs a script which adds symlinks
to busybox for all applets which are implemented in current
build of busybox, AND which doesn't exist.  So, IF no modprobe,
insmod, rmmod, or lsmod is found, it will be created as a
symlink to busybox.  So it was only the build dependency
which broke (which is what this thread is about).

Whenever it is a good idea to use busybox modprobe or not is,
again, a different question.  Since it is already used in
initramfs and apparently will be used in wheezy, I think it
should be safe to use it in d-i too.  But having in mind
beta1 of d-i should come out, any change there is, well,
unwelcome.

>>> module-init-tools is not coming back, if d-i still needs something from 
>>> kmod then just let me know without getting crazy for no reason.
>> http://hermes.jura.uni-tuebingen.de/~blank/debian/kmod.diff
> This is interesting, because the last time I tried statically linking 
> the udeb it was bigger than the dynamic one.
> -Os is supposed to be used, but now I see that it somehow broke.
> 
> I can upload a new package later today, but I want to be really sure 
> that there is a consensus to rename the udeb right now.

Thanks,

/mjt


Reply to: