[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#976462: marked as done (tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?)

Your message dated Wed, 12 May 2021 20:53:43 +0100
with message-id <YJwyR20axB2sa7+a@momentum.pseudorandom.co.uk>
and subject line Re: Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?
has caused the Debian Bug report #976462,
regarding tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
976462: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976462
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: tech-ctte

Dear members of the technical committee

I am asking for you provide advice or make a decision according
Constitution 6.1.3 on the matter of whether dbgsym files should use file
level compression or not.

I intend to use the outcome of this bug to determine how to resolve
#922744 (either by implementing the request or closing it as wontfix).


A bit of context:
=================

Since compat 9 (released in 2012-01-15), debhelper has compressed
detached dbgsym files using objcopy's option --compress-debug-section.
This was implemented in debhelper/8.9.10 in order to resolve #631985.

When -dbgsym packages was implemented several years later, I used
--compress-debug-section in the implementation as it was the default for
modern compat levels at the time.

Then on 2019-02-20, Matthias Klose filed the bug #922744, in where
Matthias (in my reading of the subject) effectively requests that
debhelper stopped using --compress-debug-section, which would overturn
the request in #631985.

The underlying arguments for and against --compress-debug-section appear
 to be "download size" vs. "installed disk usage" vs. "Tooling support".
 Though I ask you to please read the bugs #631985 and #922744 for the
details of the arguments by both proponents.


I have _not_ involved any of the parties/stakeholders in this nor heard
there arguments.  Please see "Why punt it to you?" for why.


Why punt it to you?
===================

I am punting this to you because:

 1. As stated in #922744, I am largely not emotionally invested in the
    result.  Though I admit having reservations on how the solution is
    implemented (see "Non-solutions").

 2. I am certain I do _not_ have the spoons and emotional capacity for
    resolving this in the best way for Debian (as opposed to the "least
    discussion/work for me" solution).  This has kept me from opening
    the debate with relevant stakeholders.

 3. I do not want #922744 to rot forever in the bug tracker (which is
    frankly what is happening now).

Given the nature of the underlying problem is technical, then I thought
it was best to rely on you.  My other alternative would be to throw it
at debian-devel but given point 2 in my list above that seemed like it
would be counterproductive for me.


My intentions for implementations:
==================================

If the advice/decision is to stop using --compress-debug-section then I
intend to retroactively undo the change for all compat levels (affecting
compat 9+) after the next release (to avoid disrupting the current release).
  It is my understanding that nothing relies on a 100% coverage of
compressed dbgsyms as we never got to a 100% in Debian yet.
Furthermore, most compilers do not compress debug sections by default,
which means that most tools will need to support uncompressed debug
sections to be useful.


If the advice/decision is to keep using --compress-debug-sections, I am
tempted to just leave the implementation as-is and slow migrate the rest
of the packages as the old compat levels are phased out.


I am open to changes/advice to alternative solutions for implementation
(though please see "Non-solutions") - these alternatives can be
presented anyone (including members of the tech-ctte in their private
capacity[1]).


Non-solutions:
=-=-=-=-=-=-=-

I do _not_ think we will be better served with compression being
something you opt-in/opt-out from based on a command-line option (or a
field in debian/control).  I think debhelper has way too many
"special-case" options or toggles where people have to do case-by-case
decisions already and I would see this as "yet another one".

You may choose this as a solution but then I require you to overrule me
as a maintainer using 6.1.4 with a 3:1 supermajority in the decision.

Thanks for your time,
~Niels


[1] I do not expect a full decision cycle/vote just to propose an
alternative.  But also, I do not want 6.3.5 getting in the way of a
better solution than I thought of.

--- End Message ---
--- Begin Message --- 
On Sat, 05 Dec 2020 at 13:12:32 +0100, Niels Thykier wrote:
> I am asking for you provide advice or make a decision according
> Constitution 6.1.3 on the matter of whether dbgsym files should use file
> level compression or not.

With the current information available, our decision is that debhelper
should continue to use --compress-debug-section.

This is not a requirement and is not intended to overrule a maintainer;
we have no objection to the debhelper maintainer changing this policy
if different information becomes available in future.

## In favour of compressing detached debug symbols on disk

Compressing the contents is considerably better for their Installed-Size,
enough that it can make the difference between feasible and not feasible
to keep debug symbols for packages of interest installed - particularly
for large C++ packages like web browsers and the KDE suite.

(Median Installed-Size without --compress-debug-section is around 250%
of median Installed-Size with --compress-debug-section, according to
analysis by Jakub Wilk and Elana Hashman. For large packages, not
compressing the detached debug symbols on disk can mean +5.7G of
Installed-Size.)

## Against compressing debug symbols on disk

- The .deb size (and therefore mirror size and download bandwidth
  consumption) is somewhat worse when compressed.
  (Median .deb size without --compress-debug-section is around 75%
  of median .deb size with --compress-debug-section, according to
  analysis by Jakub Wilk and Elana Hashman)

- Some toolchain and debugging tools have had bugs in the past where they
  could not deal with compressed debug symbols, e.g. in valgrind; but these
  bugs were treated as bugs upstream, and fixed.
  (https://bugs.kde.org/show_bug.cgi?id=396656,
  https://bugs.kde.org/show_bug.cgi?id=427969)

- Some debugging tools might still have similar bugs, but nobody was able
  to cite one specifically.

- Some toolchain components cannot deal with compressed debug symbols and
  this puts constraints on the order of operations in debhelper: in
  particular, dwz is not able to act on compressed debug symbols, so dh_dwz
  must run before dh_strip compresses the debug symbols. However, since
  the debhelper maintainer seems happy with the current situation, it seems
  this is not a practical problem.

- debugedit (used in Fedora to process debug symbols, for example as
  Fedora's alternative to our use of -fdebug-prefix-map) also cannot deal
  with compressed debug symbols. However, debugedit is not currently used
  in Debian builds. If we incorporate it into Debian builds in future, we
  can either run it before dh_strip like we do for dwz, or reconsider the
  use of objcopy --compress-debug-section at that time.

-- 
smcv, on behalf of the Debian Technical Committee

--- End Message ---
Reply to: