[kernel] r4901 - dists/trunk/linux-2.6/debian/arch/powerpc

[Sven Luther]

Author: luther
Date: Fri Nov 25 11:13:04 2005
New Revision: 4901

Modified:
   dists/trunk/linux-2.6/debian/arch/powerpc/modules.README
Log:
Added explanation of the experimental nature of this test, and the effect on d-i and low-mem systems.


Modified: dists/trunk/linux-2.6/debian/arch/powerpc/modules.README
==============================================================================
--- dists/trunk/linux-2.6/debian/arch/powerpc/modules.README	(original)
+++ dists/trunk/linux-2.6/debian/arch/powerpc/modules.README	Fri Nov 25 11:13:04 2005
@@ -1,3 +1,12 @@
+Just for info, and to avoid bad blood or anything, this is for now just an
+experimentation to be able to test and experiment my ideas, before it is either
+abandoned, or declared good enough to be generalized. The main caveat joeyh had
+about this when we discussed it in the past, apart from it being just words and 
+nobody doing the work behind it, was the effect the multiplication of .udeb 
+packages had on the d-i Packages file parsing on low-memory systems. Especially
+as it seems d-i maintains three simultaneous in-memory copies of this Package 
+file, not sure why exactly, but this could be obtimized maybe, but see 7) also.
+
 The plan goes as follows : 
 
   1) We will provide one .udeb per module, this will bring it to 600 or so
@@ -31,6 +40,14 @@
   chose to split its kernel-udeb packages. This needs solving before we go with
   this for all arches, so let's experiment a bit with powerpc only.
 
+  7) To ease the weight of this multiplication on .udeb packages on the d-i
+  Packages parsing, one could imagine to split off a separate Packages file for
+  each kernel flavour, residing in .../debian-installer/kernel/<version>-<abi>-<flavour>.
+  Not sure if all three d-i Packages parsing parts can handle multiple sources,
+  i think not, but this is something which it would be worth to fix independently
+  of this issue.
+
+
 Well, that is it, works needs done, but i sincerely think this is the right
 option for this, especially given the poor status of the inter-arch synchronization
 the d-i team has done with the kernel .udebs, and they rejecting all responsability