Eliminating static binaries (Was: Unwanted RPM dependencies)

[Bernardo Innocenti]

David Zeuthen wrote:
> On Mon, 2007-06-04 at 03:37 -0400, Bernardo Innocenti wrote:
>>  - mkinitrd depends on lvm2 and dmraid.  Both could easily
>>    be made optional.
> 
> You most probably don't need mkinitrd on OLPC as the kernel got all the
> drivers built-in and IIRC OLPC don't even use the initrd (when I was
> working on it, it didn't). So you could have some OLPC specific package
> that provides mkinitrd and symlinks /sbin/mkinitrd -> /bin/true or
> something.

We need mkinitrd because you can also boot from usb with the ext3
image.  The contents of jffs2 and ext3 images should be identical
to simplify distribution.

And by the way, the kernel depends on mkinitrd so we can't remove
it without breaking RPM deps.  We try to avoid kludges as much
as possible because it makes life very hard when updating the
system with tools like yum.


> Probably cryptsetup doesn't need to be linked statically anymore; Peter
> Jones would know.

Good.  But, why do we need *any* static binary in the first
place?  I don't buy the robustness argument: a 1MB binary is
equally subject to corruption than a smaller binary plus a
1MB library.

Also, I dismiss the argument that today's computers have
huge hard drives anyway so let's waste them.  Bigger hard
drives are meant to hold more data, not the same amount of
data stored in inefficient formats.  And any way, Linux is
also being used with constrained systems where 256MB of
flash storage is luxury.

Some binaries we may wont to relink dynamically:

 - /sbin/e2fsck (dynamic on debian)
 - /sbin/dmsetup.static (dynamic on debian)
 - /sbin/insmod.static (dynamic on debian)
 - /sbin/ldconfig (yes, even this one!)

And what is /sbin/sln? It's part of glibc, but it's not
documented anywhere.  Can we kick it out?

Also, the /sbin/tc and /sbin/ip binaries are quite big
despite being dynamically linked and stripped. Anybody
knows why?


> Either way, if you don't expose LUKS encrypted stuff
> in the UI I guess you can just drop the cryptsetup dep from hal since it
> will gracefully recover and just throw and error if Crypto.Setup() is
> called.

I'm not a platform developer, but from what I hear, we'd
prefer such changes to happen in Fedora, so we do not need
to maintain too many forked packages in the OLPC repo.

All Fedora users will benefit from a smaller installation
set anyway.

-- 
   // Bernardo Innocenti
 \X/  http://www.codewiz.org/