Debian Bug report logs - #185214
dump: restore should be statically linked

Full log

Message #19 received at [email protected] (full text, mbox, reply):

Received: (at control) by bugs.debian.org; 23 May 2004 16:54:20 +0000
From [email protected] Sun May 23 09:54:20 2004
Return-path: <[email protected]>
Received: from winfree.gag.com [192.133.104.8] 
	by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
	id 1BRwEu-0008FG-00; Sun, 23 May 2004 09:54:20 -0700
Received: from localhost (localhost [127.0.0.1])
	by winfree.gag.com (Postfix) with ESMTP
	id 3F262C003; Sun, 23 May 2004 10:54:20 -0600 (MDT)
Received: from winfree.gag.com ([127.0.0.1])
	by localhost (winfree [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 02984-10; Sun, 23 May 2004 10:54:18 -0600 (MDT)
Received: from rover.gag.com (rover.gag.com [192.133.104.32])
	by winfree.gag.com (Postfix) with ESMTP
	id 876D8C041; Sun, 23 May 2004 10:54:18 -0600 (MDT)
Received: by rover.gag.com (Postfix, from userid 1000)
	id 75A7882324; Sun, 23 May 2004 10:54:18 -0600 (MDT)
To: [email protected], [email protected],
	[email protected]
Subject: my thoughts on this
From: Bdale Garbee <[email protected]>
Date: Sun, 23 May 2004 10:54:18 -0600
Message-ID: <[email protected]>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at gag.com
Delivered-To: [email protected]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 
	(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-5.0 required=4.0 tests=BAYES_00,VALID_BTS_CONTROL 
	autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level: 
X-CrossAssassin-Score: 2

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

Send a report that this bug log contains spam.