On Wednesday 29 July 2009, Frans Pop wrote: > On Wednesday 29 July 2009, you wrote: > > > Just for the record, the following is NOT correct: > > > 10:09 <maks> otavio: only linux-modules-extra > > > 10:09 <maks> nothing d-i uses and nothing one should really have to > > > care. > > > > > > D-I uses the loop-aes modules (for encrypted partitioning) and that > > > is exactly why it is so hard to switch D-I to a new kernel version: > > > D-I can only realistically switch to a new kernel for an arch when > > > both the kernel itself *and* loop-aes are available. > > > > sorry to say so, > > but it is idiotic that d-i *depends* on external modules. > > *shrug* > D-I has been using loop-aes since Sarge. This is nothing new.
To clarify: D-I does not *depend* on loop-aes (as you put it), but it does *use* it. And if it is missing we have a regression in offered functionality, which is especially bad for any D-I release. Besides that, if l-m-e fails to build and is migrated to testing then any users having encrypted partitions using loop-aes will be unable to update their kernel, so treating the absence of l-m-e as a blocker for migration of the kernel seems quite correct to me. Debian has been offering support for encrypted partitions using loop-aes and if that is to be dropped it should be done in a clean way. The kernel team ignoring build failures in one of the packages it maintains is IMO not a reason to lower the normal quality criteria of the testing suite. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
