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
  .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.

  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
to porters.

Friendly,

Sven Luther