Re: HEADS-UP: Enabling WITH_DEBUG_FILES by default

On Wed, Feb 11, 2015 at 08:56:00PM -0700, Ian Lepore wrote:
> On Wed, 2015-02-11 at 22:21 -0500, Ed Maste wrote:
> > On 11 February 2015 at 21:39, Glen Barber <gjb_at_freebsd.org> wrote:
> > >
> > > Within the next 24 hours, I will merge the release-install-debug branch
> > > into head, which will enable building and installing stripped debugging
> > > files by default.
> > >
> > > In general, this should have no significant impact, but any fallout will
> > > be addressed as soon as possible after the merge.
> > >
> > > Those that do not want debugging files built/installed by default should
> > > add 'WITHOUT_DEBUG_FILES=1' to src.conf(5).  This will also be noted in
> > > UPDATING.
> > 
> > Note that the debug files do consume a reasonably large amount of disk
> > space in both the OBJDIR and in the installed location under
> > /usr/lib/debug. Users with limited disk space will probably want to
> > disable them.  As an example, the installed debug data on my laptop is
> > about 2GB.
> 
> Seriously?  2GB is bigger than the entire filesystem on many ARM boards
> that do useful work.  Not to mention how long it will take to write all
> that to an sdcard (it already takes a long time to installworld/kernel
> to an sdcard and it's only 400MB).
> 
> Just what are these files, and what use will the average user make of
> them?
> 
> What use will I make of them, that is going to justify that every one of
> my couple-dozen build sandboxes will now be 4gb larger (a copy in obj
> and a copy in the nfs root that things install to)?
> 
> How much time will this add to a build?
> 
> Yeah yeah, I can update a couple dozen src.conf files to eliminate them,
> and that's not the biggest hassle in the world (but it's also not
> nothing).  It seems like this is a heavy enough load that it needs to
> justify its existance.
> 

The major benefit is that all debugging data that we need to properly
debug application crashes in the base system will be available
out-of-box.

There is a trade-off here, in both directions.  For arm, for example,
the trade-off is that the default installed userland would grow, however
when there is a PR regarding an application crash, the tools to diagnose
the issue are there by default (we do not need to ask that the utility
is rebuilt with debugging options enabled, and then recreate the crash).

I considered making this an opt-in thing for arm, but given the above
rationale, thought it would be more beneficial for the opposite route.
If you feel necessary, however, we can turn this off by default for now
for arm.

Glen