Modestas Vainius wrote: > What in particular do you dislike about my proposal? I guess you want to get > rid of pipe() and fork() complexity.
I see no benefit to having the command communicate back to dh which options it liked, only for dh to print them. So it seems no better, only more complex, than the idea of having the command itself print the options it likes. But since dh seqauences can include arbitrary commands, which might look like debhelper commands but not know how to print their options, either approach seems flawed on that grounds. That's not why I viscerally disliked it though. I think my visceral dislike is just that either approach violates least suprise, which suggests that dh should not behave entirely unlike make WRT how it runs commands and prints what it's doing. > Btw, have you tested your solution to -Bbuild (#541773) problem? I don't see > how -O solves it. And my test confirms it does not: I've fixed that. > The problem here is bundling. So the solution would be to disable bundling > while processing DH_INTERNAL_OPTIONS (assuming dh always passes through > command options via DH_INTERNAL_OPTIONS, not only for overrides. Why not?). I > think it's a good compromise that options passed through via dh cannot be > bundled. -O does not help much in this case and just clutters output. Disabling bundling could probably only be accomplished in v8. -O allows fixing the issue for almost all cases without breaking compatability. (Aside from the insane case where someone bundles two options together, and different commands understand different options of the pair, but not both). -- see shy jo
signature.asc
Description: Digital signature
