Matthias Klose:
On 11.11.24 14:11, Niels Thykier wrote:[...]
Hi,To clarify: I am happy with keeping `dh_dwz` (and the `dwz`) as an opt-in feature. I should have mentioned that in my previous mail, but I forgot and the subject line did not do my intent justice. If nothing else, there are probably edge cases where `dwz` is useful.
This discussion is really about "should dh_dwz be on by default?", which is where I am leaning towards a no.
Apologies for any confusion this omission might have caused.
Hi Matthias,I am getting reports of `dwz` not keeping up with current developments and causing grief for packagers with arguments being that the typical optimization is 3%, which does not seem like a lot for developer time spent working around `dh_dwz` (see #1016563 for the longer list of arguments).I think, that optimization degraded when dh_strip started to compress debug sections...
The `dh_strip` command started compressing dbgsyms in compat 9 (the change was introduced in 2011 by Joey Hess, compat 9 was released in 2012-01-15). The `dh_dwz` was introduced in October 2017 (6 years later) and first made default in compat 11. At the time dh_dwz was introduced (Oct 01 2017), about 78% of all packages were using debhelper compat 9 or above (20 000+ packages).
Accordingly, I am dismissing that `dh_strip` use of compression would have degraded the optimization in any notable form, since the compression was over 3/4 at the time dh_dwz was introduced, and most consumers would have activated dh_dwz with a compat bump (rather than retrofitting it into a compat 8 or older package).
Do you have any intent to fix that?
No, I have no intent of changing that nor do I perceive anything that needs to be "fixed".
For those at home, I asked the CTTE for advice on `dh_strip` compression in #976462 where the CTTE came to the conclusion:
""" With the current information available, our decision is that debhelper should continue to use --compress-debug-section. """ https://bugs.debian.org/976462#103
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?
I do not see the benefits as outweighing the maintenance cost / added complexity for having `dh_dwz` on by default. As said at the start, maintainers can still opt-in to using `dh_dwz`.
If you want to prototype this (as an example, for Ubuntu), the `dh` command has the `DH_EXTRA_ADDONS` ENV variable to inject extra add-ons.
It might be worth looking at the binary processing done by Fedora.Unrelated, but probably also worth fixing is the seed for the debug symbols, mentioned in #968710, which didn't see any feedback. There's also the debugedit command now packaged separately for Debian.Matthias
Thanks. I suspect debuginfod might have made the problem mostly obsolete with -dbgsym packages being just a "transport" rather than something to be installed. Though, I should have a proper look at this at some point.
Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
