FYI
-------- Forwarded Message -------- Subject: Re: Idea: Using ESSTRA for -dbgsym packages Date: Thu, 7 Aug 2025 18:36:36 +0200 From: Dylan Aïssi daissi@debian.org To: Hideki Yamane henrich@iijmio-mail.jp, Takuya.Namae@sony.com CC: debian-devel@lists.debian.org, devel@lists.apertis.org
Hello Hideki and Takuya,
Le dim. 13 juil. 2025 à 21:14, Hideki Yamane henrich@iijmio-mail.jp a écrit :
You can find more detailed information in our presentation slides for the upcoming DebConf25: https://salsa.debian.org/henrich/debconf25/-/blob/main/20250718_DebConf25_ES...
Thanks, that was a very interesting talk!
This leads me to a proposal I'm excited about: enabling ESSTRA for Debian's -dbgsym packages. https://docs.google.com/presentation/d/10BWJXGchob4UsKMrSUJl1AMzrkyBQ-gJ6DbW...
That's exactly what we do in Apertis [0], instead of modifying binaries, we extract the name of the used source files from the DWARF debugging information using dwarf2sources [1] via a debhelper addon [2]. Thus, this approach is compatible with all compilers which generate DWARF information, including LLVM, Go and Rust. For each source file used, a license is associated with it through the use of a consolidated debian/copyright file (based on the result of scan-copyright [3]). Additionally, our approach handles non-binary files, like scripts, configuration and documentation which are part of the binary packages. I'm in the process of upstreaming our tools into Debian, we still have to remove Apertis specific parts, hoping that this may be useful to you.
I think we are still quite a long way from being able to enable this feature by default in Debian, but that's something I would really like and which I work on. For now, our approach fix some issues you mentioned in your talk. For instance, we don't modify the binaries (and therefore to increase their size, which is a concern for embedded use cases like where Apertis is used) instead we use already available data from DWARF info. This is a more generic method which is already compatible with Rust and Go binaries since it does not involve a plugin for GCC. And finally, it relies on Debian standard workflows (debhelper and debian/copyright), thus we don't have to modify each debian/rules. I invite you to try it once I have uploaded it into Debian. It would be great if you had the opportunity to compare the two approaches and give us some numbers for comparison. What do you think?
Best regards, Dylan
[0] https://www.apertis.org/ [1] https://tracker.debian.org/pkg/dwarf2sources [2] https://gitlab.apertis.org/pkg/debhelper/-/blob/apertis/v2026dev3/dh_setup_c... [3] https://gitlab.apertis.org/pkg/apertis-dev-tools/-/blob/apertis/v2026dev3/to...