Dylan Aïssi:
Hello Hideki and Takuya,
Le dim. 13 juil. 2025 à 21:14, Hideki Yamane <henr...@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_ESSTRA.pdf
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-gJ6DbWD9L0tCk/edit?usp=sharing
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_copyright
[3] https://gitlab.apertis.org/pkg/apertis-dev-tools/-/blob/apertis/
v2026dev3/tools/ci-license-scan
Hi,
I noticed that apertis modified the `debhelper` source package for this.
This is of course a valid solution, I wanted to highlight that there
should be less need for that with DH_EXTRA_ADDONS environment variable.
The ENV variable was developed for this purpose where people want to
prototype something new or when do custom builds. Obviously, migrating
to it now would only make sense if it would simplify matters when
maintaining the addon.
Best regards,
Niels
