Re: External install modules and compacted libc

[Joey Hess <joeyh@debian.org>]

Torsten Landschoff wrote:
> > The way modules will work is that they should only be called (or loaded)
> > if needed, so its not a matter of disabling any modules, just only
> > calling the modules you need, this is the key to shrinking the installer
> > to 1 boot disk (with everything else being fetched as required). There
> 
> I see a problem with the libc here. You know we are using a compact libc
> for the current bootdisks with only so much in it as is needed by the
> stuff in the root filesystem. If other modules will be available later
> we might need more of libc. We either need to know the list of all 
> modules which might get available or the external modules need to come
> with their own libc (which is certainly doable, only wanted to 
> put draw some attention to this problem).

Yep, I've thought on it some before. There are two approaches I've come
up with:

1) Basically, define a policy that thou shalt use only these libc
   functions in an installer module. Anyone who needs a new function has
   to get it into the policy.
2) Make sure all the installer modules are in a well-defined place in
   the debian archive, and download them all and analyize them all for
   library reduction. Each time a new version of a module is uploaded,
   we may need to update the libc to make sure it supports the symbols
   in it.

The problem with 1 is that it introduces some very Debian-eque
beauracracy, and third parties who make installer modules need to
consult the approved function list.

The problem with 2 is it requires more work, and third parties who make
installer modules have to consult some list still, except the list may
change without warning..


Including the libc with the modules doesn't seem any better than just
statically linking the modules. Which I guess a third party could do in
some situations in any case.

-- 
see shy jo