Hello, On trečiadienis 06 Sausis 2010 20:43:36 Joey Hess wrote: > 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.
It would be great if dh could do this without actually invoking debhelper
command. But with current design it is hardly possible.
> 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.
Possible but how likely?
if (basename($command) !~ /^dh_/) { print manually... } should be pretty safe.
> 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.
My main intentions with this bug were:
1) I don't like how dh pollutes output with options most debhelper commands do
not care about. Seeing --dbg-package near dh_install with -O or without it
looks plain confusing in my eyes. Both `dh_install -O--foo` and `dh_install -
O--bar` will do the same thing (because both options are not supported) while
output implies otherwise until you read dh_install(1) manpage (and now
debhelper(7) manpage to figure out what -O means). What is more, it is
absolutely not clear what commands actually process those options. *Sigh* to
my disappointment, it seems that's how it's going to stay so nevermind.
2) The worst part is how debhelper commands are executed via overrides. It is
still black magic because dh automagically sets some undocumented option
DH_INTERNAL_OPTIONS which debhelper commands react to. To make things worse,
output of the real make(1) simply *lies* about what options are actually
passed to debhelper programs. In order to close this bug, those hidden options
will have see a documented daylight somehow.
> > 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.
It seems so.
> > 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).
It would not hurt for options passed to dh(1).
--
Modestas Vainius <[email protected]>
signature.asc
Description: This is a digitally signed message part.
