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
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.
Reply to: