59 lines
3.0 KiB
Plaintext
59 lines
3.0 KiB
Plaintext
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
|