Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?
On 3/8/21 6:27 PM, Sam Hartman wrote:
>>>>>> "Matthias" == Matthias Klose <doko@debian.org> writes:
>
> Matthias> Maybe you should be more specific about "those who can't
> Matthias> use" uncompressed debug info in the first place.
>
> So, you've argued that the disk savings are not significant inside a
> package, because packages are themselves compressed.
>
> What people are arguing is that they want to have debug info for large
> programs like firefox or chromium installed, or really debug info for
> large parts of their system.
> They are in effect arguing that they care about the installed size not
> the package size.
> They have explicitly argued that having to uninstall and then later
> reinstall disadvantages their debug cycle.
>
> This situation is particularly unfortunate because it sounds like we
> have a conflict between two techniques for saving space.
>
> On one hand we have dwz which tries to optimize and reduce overall size
> of debug symbols
>
> which is incompatible (apparently--no one has explicitly confirmed this)
> compressed debug symbols.
>
> Presumably we can still run dwz within a single package by doing so
> before debug symbols are compressed.
> But presumably this gets in the way of people running dwz themselves or
> something.
>
> I'll be blunt.
> The people who say that they want debug symbols installed on their
> system have made a simple, easy to understand argument.
let my be blunt as well. The only reference I can find regarding the size on
disk is #922744. Contrary to what you're saying "that they want to have debug
info for large programs like firefox *or* chromium installed", they want to have
debug symbols for firefox *and* chromium *and* more installed at the same time.
#631985 speaks about a 10G space requirement for debugging KDE alone.
The decision about the compressed debug symbols was made ten years ago. Maybe
it's time to re-evaluate what expectations for a debug installation should be set.
> The argument that compressed debug symbols break things is still porrly
> stated.
> We've had a claim that dwz might not work with compressed debug symbols
> (and didn't used to).
> We've had no one explain how that creates a problem in practice or even
> confirm it's still the case.
> It felt like pulling teeth to even get an answer that might be a tool we
> care about.
#878888 asked for "postprocessing in dh_strip", however it was implemented in
* dh_dwz: Add new experimental tool to run dwz(1) to deduplicate
ELF debugging symbols. It should be generally be run before
dh_strip (as dh_strip compresses the debug symbols and dwz
expects uncompressed debug symbols). (Closes: #878888)
as pre-processing. So we know since about three years that dwz doesn't support
compressed debug symbols. Your language about "claims", "might", and so on is
not appropriate.
Upstreams are currently looking at issues seen with valgrind about
.gnu_debuglink section and .gnu_debugaltlink section in
https://bugs.kde.org/show_bug.cgi?id=427969
https://bugs.kde.org/show_bug.cgi?id=396656
so apparently there are issues with another tool (valgrind), and how the debug
information is created and split in debhelper.
Also see
https://github.com/rpm-software-management/rpm/blob/master/scripts/find-debuginfo.sh
how dwz is run *after* separating the debug info, not touching the stripped
binaries.
Apparently the choice for compressed debug sections resulted later in an
implementation for dh_dwz which is causing issues on it's own.
Unrelated to that, but to not create conflicting dbg and dbgsym packages, there
is #968710 and #981245, and it will be difficult to integrate within debhelper
without introducing a new debhelper compat level.
Also unrelated, there are #971724, #971680, and packages manually installing
additional files in auto-generated dbgsym packages.
Maybe any of these decisions to dh_strip were maybe mad to the best knowledge at
the time, but the current situation is a mess. Sticking to compressed debug
sections is just one issue ...
Matthias
Reply to: