From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9056 invoked by alias); 11 Jun 2003 14:15:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9030 invoked from network); 11 Jun 2003 14:15:09 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 11 Jun 2003 14:15:09 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h5BEF9H21526; Wed, 11 Jun 2003 10:15:09 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5BEF9I11493; Wed, 11 Jun 2003 10:15:09 -0400 Received: from localhost.localdomain.redhat.com (vpn50-23.rdu.redhat.com [172.16.50.23]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5BEF1E25092; Wed, 11 Jun 2003 10:15:08 -0400 To: Jim Blandy Cc: gdb-patches@sources.redhat.com, binutils@sources.redhat.com Subject: Re: RFC: Support for separate debug info files References: <20030611134326.GA13158@nevyn.them.org> From: Nick Clifton Date: Wed, 11 Jun 2003 14:15:00 -0000 In-Reply-To: <20030611134326.GA13158@nevyn.them.org> (Daniel Jacobowitz's message of "Wed, 11 Jun 2003 09:43:26 -0400") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00370.txt.bz2 Hi Daniel, >> > My theory is that the only benefit gained by being able to ship a >> > stripped debuginfo file as opposed to an unstripped one is that it >> > reduces the shipping size, making a distribution smaller. I am >> > assuming that hard disk space is not really an issue, just the size >> > of the shipped binaries. >> >> I think the idea is to omit the debug info files altogether from the >> distribution. It'll make the debug info packages take longer to >> download, but it's not a show-stopper, I think. > > For me it probably is a show-stopper - the issue is not download time > or disk space, but CD size. Duplicating all the binaries we want to > provide debug info for would probably push us over the edge. It could > be done separately though! This will at least let us test it... Plus you could ship the debug info CD separately. Maybe at additional cost to the customer, or after a delay, so that the time-to-market for a new release is reduced ? Cheers Nick