Matthias Klose: > On 29.09.19 11:08, Niels Thykier wrote: >> Control: tags -1 moreinfo >> >> On Tue, 24 Sep 2019 09:07:16 +0200 Matthias Klose <d...@debian.org> >> wrote: >>> Package: debhelper >>> Version: 12.6.1 >>> >>> For packages needing debug information for backtraces or stack >>> unwinding in the >>> binary itself, it's not possible to pass custom strip optons to >>> strip, having to >>> mimic the dh_strip behavior in the rules when you require different >>> options for >>> stripping. Also with the proposed new CTF debug format package might >>> want to >>> keep the relatively small CTF overhead instead of the rather large >>> DWARF debug >>> information. >>> >>> There is also discussion at [1] how upstream strip should handle >>> stripping CTF. >>> >>> [1] https://sourceware.org/ml/binutils/2019-09/msg00209.html >>> >>> >> >> I am getting mixed signals from this bug report. AFAICT, upstream wants >> CTF never to be stripped. While we can argue whether that is what we >> want, I don't see how it is related to passing custom options to strip. > > well, then let's separate the ctf issue and the passing of custom > options (and I found again #595810). >
Indeed, I thought of #595810 as well when you filed this bug. For reference, Joey Hess's remark in that bug (comment #10) is still relevant today: """ I guess I could make options after dh_strip -- be passed on to strip, but I don't think that would simplify the rules file much, unless all binaries in the package need to be stripped like that. """ > [...]>> As for passing custom options: >> * How many cases do you have where you need to pass custom options and >> it is the *same* custom options for every ELF binary/static lib in >> that debian package? > > How would you build an openjdk-11 dbgsym package with custom options > applied, so that the jmap tool is still working? The current source > builds a manual dbg package and already has to re-implement the dh_strip > logic. If you need to replicate the logic to build a dbgsym package, > then that's even more duplication. > The dh_strip tool (like many other dh_tools) work on a package level. Doing fine-grained "per-file" controls is beyond what can be supported in the dh_strip design. In fact, very few dh_* tools support "per-file" level decisions (for anything more complicated than a target dir or similar). > What am I missing for that use case? Either a "Yes, every binary in that package needs the same options" (Joey's message) or a replacement tool for dh_strip that works on a "per-file" level, which will imply a fundamentally different design than what dh_strip has right now. If you need the latter, then please prototype it outside debhelper to stabilize its interface. If it is a successful replacement for dh_strip and its implementation compatible with debhelper's design, then I will happily consider to merge it in and have it replace dh_strip. Thanks, ~Niels
