Package: dgit
Version: 9.7
User: d...@packages.debian.org
Usertags: rsn

Félix Sipma writes ("Re: dgit for DM [and 1 more messages]"):
> On 2019-08-14 08:00+0100, Ian Jackson wrote:
> > Félix Sipma writes ("Re: dgit for DM [and 1 more messages]"):
> >>    (~/src/khard)$ dgit sbuild --gbp 
> > 
> > The --gbp is an option to dgit.  "dgit sbuild" is followed by options
> > to sbuild.  Of course sbuild wouldn't recognise "--gbp" but dgit
> > doesn't get that far...
> > 
> > Try
> >   dgit --gbp sbuild
> 
> Thanks. I finally found it by myself but maybe it would be nice to have
> something like "Maybe you meant 'dgit --dgit-option sbuild'?" message to
> users running 'dgit sbuild --dgit-option', to give them a clue of what
> could be wrong?

This is a good idea; thanks for the suggestion.  (I trust you don't
mind me leaking your private emails to me to the BTS in this way.)

It's rather a layering violation: it means dgit has to peer into
sbuild's options.  dgit won't get this 100% right (eg, I don't think
it is sensible for dgit to try to accurately distinguish sbuild
options from values passed to those options), so dgit may become
confused.  But if the only effect is to print a warning message to
stderr, that's probably OK.

I think it's possible that dgit's code for massaging arguments to
dpkg-buildpackage (used for all the non-sbuild builders) already does
this.  That needs to be checked.

I think not all dgit options would have to be spotted, because: if
dgit's own work had succeeded and it had invoked sbuild, sbuild would
have printed a message about --gbp, making the situation reasonably
obvious.  And short options are too ambiguous.  So I don't propose to
somehow reuse dgit's own option parser code (or table-ify it).  We'll
just have an ad-hoc list of things to warn about.  To be clear an
option should be included if
  - it might avert an error which prevents dgit from running sbuild
     (eg quilt options, --ignore-dirty)
  - it might avert processing which dgit does before running sbuild
     but which the user presumably didn't intend (eg --dry-run, -w*)
(For sbuild, read "the builder".)

Tagging this rsn because I think it is a fairly easy useability
improvement, if done in the ad-hoc way I propose above.

Thanks,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply via email to