[kernel] r4900 - dists/trunk/linux-2.6/debian/arch/powerpc
Sven Luther
luther at costa.debian.org
Fri Nov 25 09:29:52 UTC 2005
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
More information about the Kernel-svn-changes
mailing list