Re: External install modules and compacted libc
Torsten Landschoff wrote:
>
> On Fri, Sep 22, 2000 at 06:04:49PM -0700, Joey Hess wrote:
>
> [compacted libc problem]
> > 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.
>
We can still have a non-striped libc (minus option?) in a module that
could be installed if it was needed. Library reduction is really only
critical for modules that will go on a boot/root floppy, modules that
will be sourced post bootup are less critical on space, it is likely
further modules will be residing on hard disk, cd or via the network. We
have to install the full libc sometime.
Supporting unplanned binaries is the big problem with stripped libc,
this may be a strange idea, would it be possible at runtime to detect if
a binary has failed due to unsupported libc?
If we could detect the problem we could (try to) install the non-striped
libc, a bit like auto-apt.
>
> > 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.
>
> If the module comes on CD I see no problem with including the libc.
>
If there is a dependency heirarchy in the modules, then the libc symbols
included would only have to be those symbols not suplied by previous
modules.
Glenn
Reply to: