On Tuesday, November 19 2024, Adrian Bunk wrote: > On Tue, Nov 19, 2024 at 02:26:39PM +0100, Matthias Klose wrote: >> On 11.11.24 14:11, Niels Thykier wrote: >>... >> > Currently, we are looking at about 260 packages that are tweaking or >> > working around `dh_dwz` in its current form (search for >> > `override_dh_dwz` on codesearch.d.n) in some way or another. >> > >> > I think we should reconsider having `dh_dwz` on by default. At this >> > point, I am contemplating to pull it out in compat 14. >> >> Can you consider keeping that on architectures, where dwz is used by >> Fedora/RedHat? >>... > > Why would this be desirable?
I don't speak for doko, but I believe his request has to do with the fact that Red Hat is the upstream maintainer of dwz and as such it's still possible to see progress in the architectures maintained by them. > This is not a rhetorical question. > > Quoting from my original bug report 2 years ago: > > These optimizations are only in the -dbgsym packages that nearly > noone installs and nearly noone uses. > > Debug info is super useful when needed, but it is not installed by > default and dwz optimizations have little practical relevance in the > cases when it is used. > > Buildd speed is a larger bottleneck than server space, even if dwz > worked flawlessly I could only barely see how it is worth it. I find it strange (and I'm not doubting your numbers) that dwz is only contributing to a 3% reduction in the final debuginfo size. dwz works by removing duplicated DIEs from the debuginfo, which is an approach that shouldn't really be affected by the compression performed by dh_strip (which happens at the filesystem level). Either way, if the real gain is so low then I tend to agree with this proposal. > Regarding limiting dwz to Fedora/RedHat architectures, we have in the > past years seen plenty of cases where dwz choked on all architectures > on what e.g. a new LLVM version produced. > > Is there any benefit of dwz I miss? The main benefit should be the size reduction. Let me also say that we "now" (since 2021) have a debuginfod instance (which isn't official yet, unfortunately), which might make this discussion a bit moot because then the size reduction would only really matter for the Debian debuginfod server anyway. But of course, because the instance is not official yet it means that less people than I'd like are actually using it. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
