Your message dated Wed, 12 May 2021 20:53:43 +0100 with message-id <[email protected]> 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 [email protected] immediately.) -- 976462: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976462 Debian Bug Tracking System Contact [email protected] 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 ---
