release: Use "debug info" for lib32 set description

[jhb]

Summary

This mirrors the changes applied to kernel debug symbol sets in commit
9a354a41be9a40c3c0a16cc20f4009d3b31679cc.

Sponsored by: AFRL, DARPA

[ivy]

in pkgbase, we use " (debugging symbols)" for this. i think this change is fine to make the manifests consistent, but i wonder if it's worth changing everything to use the same term. (but with freebsd.org dist set builds going away in 16, this might not matter.)

[emaste]

"debugging symbols" isn't best, because these are not just symbols.

[jrtc27]

-g, -gline-tables-only, -gmodules

	    Control debug information output

debuginfod serves debuginfo-related artifacts over HTTP

debug info is indeed a better term to use (sometimes debug data instead, e.g. in hier(7) and src.conf(5)). As Ed says, it's more than just symbols, you've got source mappings, unwind info, and local variable materialisation info, to name a few.

[emaste]

We should probably pick one and use it consistently. Some quick git grep showed the following counts in our tree:

debugging information	513
debugging info	81
debugging data	6
debug information	514
debug info	1256
debug data	114

This is across the whole tree and some of these might not be appropriate in context but it is indicative.

For comparison, 73 debug symbols and 28 debugging symbols.

[jrtc27]

IMO it's fine to mix abbreviated and full forms of the same term (and I guess the mix-and-match "debugging info" and "debug information"); you wouldn't want the long form here as the dialog is quite small, but that's fine in prosaic text. But yes, the "data" ones should be converted over. Sometimes we also say "files", but that's also fine as it's talking about the files themselves not their contents (though one might argue they should be "debug(ging) info(rmation) files").