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

[Sven Luther]

Author: luther
Date: Fri Nov 25 09:29:52 2005
New Revision: 4900

Added:
   dists/trunk/linux-2.6/debian/arch/powerpc/modules.README
Log:
Added a little explanation document of the work to be done. 


Added: dists/trunk/linux-2.6/debian/arch/powerpc/modules.README
==============================================================================
--- (empty file)
+++ dists/trunk/linux-2.6/debian/arch/powerpc/modules.README	Fri Nov 25 09:29:52 2005
@@ -0,0 +1,41 @@
+The plan goes as follows : 
+
+  1) We will provide one .udeb per module, this will bring it to 600 or so
+  .udebs for powerpc, for the three flavours (not counting apus or upcoming
+  nubus/legacy-iseries).
+
+  2) Each udeb description will be taken from the appropriate Kconfig file in
+  the future, not sure how to best do that, though, we could match the modules
+  to Makefiles, and then to CONFIG_ entries, which we take the description
+  from the corresponding Kconfig. Maybe a better solution would be to list the
+  modules per CONFIG_ entry, and make one .udeb per main CONFIG_ option. This 
+  would be easier to track in the long end also.
+
+  3) Module/udeb dependency is taken from the depmod output or directly from
+  the modules.
+
+  4) In the future, we should list only the main CONFIG_ options, and package
+  the modules in grouping, and list only the modules we actually need.
+  The modules only pulled in by dependency should be automatically split out
+  into packages that should never be used directly, and in a minimum way, using
+  a bit of graph analysis to determine the minimum set of such packages.
+  The problem with that is how to take the name and description of those
+  non-primary packages in an automated way.
+
+  5) We really need a way to make the config option choice / module list more
+  robust, as the split-config thingy is not all that sane right now, and there
+  is no easy link from modules to config options. Needs more investigation.
+
+  6) It may be possible that the packaging infrastructure still has some
+  trouble with this approach, even after those 2 years or so since the d-i team
+  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.
+
+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
+to porters.
+
+Friendly,
+
+Sven Luther