Hi!

On Sun, 2018-07-22 at 13:28:40 +0200, Christoph Biedl wrote:
> Package: dpkg-dev
> Version: 1.19.0.5+b1
> Severity: wishlist

> [ My gut feeling tells me I've reported this before - but I couldn't find it ]

It didn't ring a bell. :)

> dpkg-gencontrol might emit two warnings that look quite similar but
> have a rather different meaning:
> 
> | dpkg-gencontrol: warning: Depends field of package <package>: unknown 
> substitution variable ${<var>}
> 
> | dpkg-gencontrol: warning: package <package>: unused substitution variable 
> ${<var>}
> 
> Even after several years of encountering these (and fixing, of course),
> I still get confused. Especially if only one of the both messages
> appear, it's likely to get the meaning of "unknown" and "unused" the
> wrong way.
> 
> So I'm asking to reword these, and - more important - to include a
> suggestion for the maintainer, like the following:
> 
> | dpkg-gencontrol: warning: Variable ${<var>} was not listed in 
> debian/control for package <package> but is used - consider adding it
> 
> | dpkg-gencontrol: warning: Variable ${<var>} was listed in debian/control 
> for package <package> but is not used - consider removing it
> 
> Yes, these messages are longer than the current ones. But I think it's
> worth it.

This would miss the context that was present before (the field name at
least). The recommendation I think might make more harm than good,
because in many cases the fact that the variable is unknown/undefined
or not used is on purpose, say with misc:Depends, which might be
emitted with older debhelper but not newer, but could start emitting
with even newer versions. Or something sets a substvar that we do not
want to use.

Regarding clarifying the messages, I think debian/control should be
obvious from the command emitting these warnings? :) I guess we could
list it but then it needs to be parametrized, as that's settable from
the command-line. Also Dpkg::Substvars has no knowledge of where the
variables being substituted come from (file nor field, etc), which
makes creating a string that can be easily translated more difficult.

Would perhaps just changing unknown for undefined help with the
confusion? Or perhaps rephrasing them to something along the lines
of:

 * unknown → substitution variable ${var} used, but was never defined
 * unused  → substitution variable ${var} unused, but is defined

Thanks,
Guillem

Reply via email to