Subject: my thoughts on this

From: Bdale Garbee <[email-masked]>
Date: Sun, 23 May 2004 10:54:18 -0600

tag 185214 +wontfix
thanks

There are two problems with adding a static restore to the dump package.  The
first is that the binary gets a lot larger, the other is that it means I'd have
to track security updates in glibc, etc, and upload new versions of dump more
often to keep the statically linked binary from being a security issue.

My approach is to implement a "reasonable compromise" in which all of the libs
that live outside of /lib are statically linked... which right now means the
z and bz2 libs which typically reside in /usr/lib.  This results in only a 
small increase in the size of the binaries and resulting package, and if used
on a root (or recovery?) filesystem with the right library version, should work
fine even in minimal recovery scenarios.

Note, however, that the Debian installation media uses library reduction
techniques to control the size of the image, so if you want to run a binary
that wasn't part of the image at build time you need to make sure the right
library routines are available, or use a fully static binary.  Be aware of this
when planning for disaster recovery.

It's not hard to build a static version, you just need to revert my changes in
the configure script and add --enable-static to the configure call in the 
debian/rules file and the package will build static binaries.  If someone wants
to offer up a patch that makes this easier, perhaps by adding a "static:" 
target to the rules file, I could be supportive.

Bdale