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

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

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


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,

[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.

Reply to: