Bug#847972: man: Eliminate warnings from '*roff' about the undefined register 'F'

[Russ Allbery]

Bjarni Ingi Gislason  writes:
> On Sat, Dec 17, 2016 at 11:24:57AM -0800, Russ Allbery wrote:
>> Colin Watson  writes:

>>> I can see that that is attempting to avoid a warning.  However, it is
>>> not quite correct.  It should probably be something like this instead:

>>>   .if !r F .nr F 0

>>> I think ".if !\nF .nr F 0" is basically a no-op, even when warnings are
>>> taken into account.  It does arrange that if F was previously
>>> initialised to a negative number then it will be set to 0 instead (since
>>> negative numbers are falsy in groff), but I don't think that matters
>>> much since the subsequent test is "\nF>0" anyway.

>> I've reverted this code to the earlier version of:

>   This is the wrong thing to do.  Remove my patch.  It only eliminates a
> symptom, not the cause of it.  The real one is to add "-rF0" to the
> definition of "troff" and "nroff" (see "/etc/manpath.config" or
> "/etc/man_db.conf") in "man-db".  Any user can add this to its personal
> configuration file, until this bug in "man-db" is fixed.

I'm afraid I don't agree.  I'm going to go with this solution to eliminate
the warning.  I think it's the least intrusive and puts the burden of
managing these special-use registers in the correct place (in pod2man,
which is the program that decided to assign a meaning to it, rather than
in man or nroff, which doesn't and shouldn't have any special knowledge of
it).

-- 
Russ Allbery (r...@debian.org)   

Bug#847972: man: Eliminate warnings from '*roff' about the undefined register 'F'

[Bjarni Ingi Gislason]

On Sat, Dec 17, 2016 at 11:24:57AM -0800, Russ Allbery wrote:
> Colin Watson  writes:
> 
> > I can see that that is attempting to avoid a warning.  However, it is
> > not quite correct.  It should probably be something like this instead:
> 
> >   .if !r F .nr F 0
> 
> > I think ".if !\nF .nr F 0" is basically a no-op, even when warnings are
> > taken into account.  It does arrange that if F was previously
> > initialised to a negative number then it will be set to 0 instead (since
> > negative numbers are falsy in groff), but I don't think that matters
> > much since the subsequent test is "\nF>0" anyway.
> 
> I've reverted this code to the earlier version of:
> 
  This is the wrong thing to do.  Remove my patch.  It only eliminates a
symptom, not the cause of it.  The real one is to add "-rF0" to the
definition of "troff" and "nroff" (see "/etc/manpath.config" or
"/etc/man_db.conf") in "man-db".  Any user can add this to its personal
configuration file, until this bug in "man-db" is fixed.

> .de IX
> ..
> .nr rF 0
> .if \n(.g .if rF .nr rF 1
> .if (\n(rF:(\n(.g==0)) \{\
> .if \nF \{\
> .de IX
> .tm Index:\\$1\t\\n%\t"\\$2"
> ..
> .if !\nF==2 \{\
> .nr % 0
> .nr F 2
> .\}
> .\}
> .rr rF
> 
> which does seem to work, and suppresses the warning.  This was changed
> because of blank leading pages on HP-UX, but that was later tracked down
> to the missing \ at the end of \{ lines, so I can just fix that directly
> and keep the more complex code.  Assuming I understand this correctly,
> this uses the r test on groff where it's supported, and just
> unconditionally tests \nF elsewhere where the warnings are just the price
> we pay.
> 
> This will be in the next podlators release (no schedule yet for that,
> since I don't think this is too serious of an issue).
> 
> -- 
> Russ Allbery (r...@debian.org)   

  The default action of "man-db" is to remove ALL warnings from "groff",
even when the option "--warnings=..." is used (including the default "mac",
if the "..." is an empty string).

-- 
Bjarni I. Gislason

Bug#847972: man: Eliminate warnings from '*roff' about the undefined register 'F'

[Bjarni Ingi Gislason]

On Wed, Dec 14, 2016 at 12:09:37AM +, Colin Watson wrote:
> On Tue, Dec 13, 2016 at 11:17:18PM +, Bjarni Ingi Gislason wrote:
> > On Mon, Dec 12, 2016 at 06:40:21PM -0800, Russ Allbery wrote:
> > > Apologies for the regression; this is the confluence of two things that
> > > basically no one ever does (enable nroff warnings, and use this obscure
> > > indexing code), so it's essentially never tested.
> > > 
> > > >   1) 'F' is not a random register in manual pages.
> > > 
> > > It is, though.  It's a completely random register picked by Tom
> > > Christiansen years and years ago to hang this feature off of because it
> > > wasn't used for anything else.  From the nroff and man-db perspective,
> > > it's just some random user-defined register, not anything special.
> > 
> >   I have a different conception of "random".  The variable 'F' is in all
> > manual pages, that "pod2man" creates.
> 
> It is "random" from man-db's point of view, because it has no standard
> or predictable meaning across the set of all manual pages.
> 

  It is just undocumented.  "pod2man" uses it for input; its meaning is just
documented there.  By documenting it better there, and in the manual pages
of all implementations of "man", problems are avoided.  A warning about it
being undefined avoids future trouble and time theft, when the cause of the
warning is fixed.

  It has a definite meaning in pages made by "pod2man".  It is not used in
other manual pages as an input register, if it would, it would then be a bug
in them, and nowhere else.  Call it a reserved name (by custom or tradition)
for an input register to manual pages.  I have not found an use of a numeric
register 'F' in manual pages, except in those created by "Pod::Man".


> pod2man is just one way to create input files for nroff, and man-db pays
> it no special consideration beyond just generally making sure that it
> can parse its output properly.  Some other manual page or manual page
> generator might quite legitimately define the 'F' number register to do
> something completely different.  (It would not surprise me to find some
> page deciding to use it for something to do with input file names, like
> \n[.F], or fonts, like \n[.f], for instance.)  man has no business
> predefining 'F' by default simply in order to work around a pod2man bug;
> doing so might well cause problems elsewhere.
> 

  "man has no business ..." is your belief, which is wrong.  It is
responsible for providing the commands it uses with the correct input,
correct parameter.

  Where is this bug in "pod2man" (manual page) and what exactly is it, and
why?

> Even if this predefinition didn't happen to cause any problems today,
> it's completely the wrong layer for the fix, and would be terrible
> software engineering.  Fix problems at the layer where they arise; don't
> patch around them elsewhere.  That way lies spaghetti architecture.
> 

  The problem arises inside "groff", it issues a diagnostic, not the code in
the manual page.  Proof it otherwise.

  Possible later problems are then caused by the wrong or premature use of
this name 'F' in other places.

  The problem arises (has its beginning) inside "man" when it runs "groff".
So it arises in that layer, not later, although it is only reported later in
the row (pipe).  Otherwise it could not be fixed there (in the "man" or in
its defined environment).  Proof it otherwise.

> > Besides that, it is an "input variable"(!) for "*roff".
> 
> I'm not sure what your exclamation mark signifies or why you believe
> this makes a difference.  pod2man may have set things up so that you're
> expected to predefine that variable in order to enable this indexing
> thing, but that doesn't mean it should be given any special
> consideration by man-db.  Again, it's simply the wrong layer.
> 

  A value of an input variable is in the environment of a command, not
inside it.

  "man" gives "MANROFFOPT" a special consideration, thus everything in it,
for example "-rF0".

  Why is it the wrong layer?

  If true, a change in that layer can't make the diagnostic from "groff" go
away, make it unnecessary.  But is does, by a least three methods, all in the
"man"-layer (or "man-db"-layer), outside of "groff" and the manual page.

> >   So there are only two small changes needed to "man.c":
> > 
> > 1) The default value of "roff_opt" is "-rF0" and not an empty value.  Plus a
> > comment about the reason.
> > 
> > 2) Adding an explanation to the manual, saying what the default value is and
> > why.
> 
> You can absolutely set this environment variable locally as a workaround
> to make the (off by default anyway!) warnings go away; this kind of
> thing is why that variable exists, and I'm glad you find it useful.
> However, for the reasons given above I won't change man-db in the way
> you propose.  The fix belongs in pod2man.
> 

  Why just locally (for one user)?

  Why a workaround?

  A workaround caused by what bug?

  A workaround usually means, that 

Bug#847972: man: Eliminate warnings from '*roff' about the undefined register 'F'

[Russ Allbery]

Colin Watson  writes:

> I can see that that is attempting to avoid a warning.  However, it is
> not quite correct.  It should probably be something like this instead:

>   .if !r F .nr F 0

> I think ".if !\nF .nr F 0" is basically a no-op, even when warnings are
> taken into account.  It does arrange that if F was previously
> initialised to a negative number then it will be set to 0 instead (since
> negative numbers are falsy in groff), but I don't think that matters
> much since the subsequent test is "\nF>0" anyway.

I've reverted this code to the earlier version of:

.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{\
.if \nF \{\
.de IX
.tm Index:\\$1\t\\n%\t"\\$2"
..
.if !\nF==2 \{\
.nr % 0
.nr F 2
.\}
.\}
.rr rF

which does seem to work, and suppresses the warning.  This was changed
because of blank leading pages on HP-UX, but that was later tracked down
to the missing \ at the end of \{ lines, so I can just fix that directly
and keep the more complex code.  Assuming I understand this correctly,
this uses the r test on groff where it's supported, and just
unconditionally tests \nF elsewhere where the warnings are just the price
we pay.

This will be in the next podlators release (no schedule yet for that,
since I don't think this is too serious of an issue).

-- 
Russ Allbery (r...@debian.org)   

Bug#847972: man: Eliminate warnings from '*roff' about the undefined register 'F'

[Colin Watson]

On Tue, Dec 13, 2016 at 11:17:18PM +, Bjarni Ingi Gislason wrote:
> On Mon, Dec 12, 2016 at 06:40:21PM -0800, Russ Allbery wrote:
> > Apologies for the regression; this is the confluence of two things that
> > basically no one ever does (enable nroff warnings, and use this obscure
> > indexing code), so it's essentially never tested.
> > 
> > >   1) 'F' is not a random register in manual pages.
> > 
> > It is, though.  It's a completely random register picked by Tom
> > Christiansen years and years ago to hang this feature off of because it
> > wasn't used for anything else.  From the nroff and man-db perspective,
> > it's just some random user-defined register, not anything special.
> 
>   I have a different conception of "random".  The variable 'F' is in all
> manual pages, that "pod2man" creates.

It is "random" from man-db's point of view, because it has no standard
or predictable meaning across the set of all manual pages.

pod2man is just one way to create input files for nroff, and man-db pays
it no special consideration beyond just generally making sure that it
can parse its output properly.  Some other manual page or manual page
generator might quite legitimately define the 'F' number register to do
something completely different.  (It would not surprise me to find some
page deciding to use it for something to do with input file names, like
\n[.F], or fonts, like \n[.f], for instance.)  man has no business
predefining 'F' by default simply in order to work around a pod2man bug;
doing so might well cause problems elsewhere.

Even if this predefinition didn't happen to cause any problems today,
it's completely the wrong layer for the fix, and would be terrible
software engineering.  Fix problems at the layer where they arise; don't
patch around them elsewhere.  That way lies spaghetti architecture.

> Besides that, it is an "input variable"(!) for "*roff".

I'm not sure what your exclamation mark signifies or why you believe
this makes a difference.  pod2man may have set things up so that you're
expected to predefine that variable in order to enable this indexing
thing, but that doesn't mean it should be given any special
consideration by man-db.  Again, it's simply the wrong layer.

>   So there are only two small changes needed to "man.c":
> 
> 1) The default value of "roff_opt" is "-rF0" and not an empty value.  Plus a
> comment about the reason.
> 
> 2) Adding an explanation to the manual, saying what the default value is and
> why.

You can absolutely set this environment variable locally as a workaround
to make the (off by default anyway!) warnings go away; this kind of
thing is why that variable exists, and I'm glad you find it useful.
However, for the reasons given above I won't change man-db in the way
you propose.  The fix belongs in pod2man.

Regards,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#847972: man: Eliminate warnings from '*roff' about the undefined register 'F'

[Bjarni Ingi Gislason]

On Mon, Dec 12, 2016 at 06:40:21PM -0800, Russ Allbery wrote:
> Bjarni Ingi Gislason  writes:
> 
> >   1) The comment is wrong, because the code was changed from what it
> > originally was (in my patch in the original bug report; see the last
> > line of my input in the first e-mail of this thread).
> 
> Well, the comment is correct in that this is what is being attempted.  :)
> Apparently it isn't working again.
> 
> Your original patch caused problems on HP-UX, which is why it was changed
> upstream.  See:
> 
> https://rt.cpan.org/Public/Bug/Display.html?id=92979
> 

  I found my patch to be too complicated.  A simpler and correct solution is
worded at the end of this e-mail.

> However, I think all those changes may have not been necessary and only
> the missing backslashes were necessary and your original patch was
> otherwise fine once those backslashes are added (and possibly more correct
> in avoiding warnings).  I'll give that a try.
> 

  There is no need for any changes (from the original).  My patch was at the
wrong place.

> Apologies for the regression; this is the confluence of two things that
> basically no one ever does (enable nroff warnings, and use this obscure
> indexing code), so it's essentially never tested.
> 
> >   1) 'F' is not a random register in manual pages.
> 
> It is, though.  It's a completely random register picked by Tom
> Christiansen years and years ago to hang this feature off of because it
> wasn't used for anything else.  From the nroff and man-db perspective,
> it's just some random user-defined register, not anything special.
> 

  I have a different conception of "random".  The variable 'F' is in all
manual pages, that "pod2man" creates.  Besides that, it is an "input
variable"(!) for "*roff".

> Honestly, there's part of me that just wants to drop this entire feature
> from Pod::Man, since I'm dubious that anyone actually runs roffitall more
> than once every five years or so, or that it's worth maintaining all this
> rather opaque code to support.  But I try to be intensely backward
> compatible about Pod::Man.
> 

  There is no need to change anything.

  While thinking about my suggestion of adding '-rF=0' to the code of "man"
(hard-coded addition), I realized that it was a bad idea.  Better to add it
as an option to "man", but option "-r" is already used by it.  So an
environmental variable should be better.  It could then contain all options
that "*roff" accepts.  A name like "ROFFOPTIONS" occurred to me.

  (Not sure if the following is really correct, as my memory is not so
reliable.)

  While reading the code of "man", I saw the name "MANROFFOPT" (was
searching for "ROFFOPT" (short for "ROFFOPTIONS").  Checking the manual page
of "man", this was exactly the environmental variable I was interested in.

  So there are only two small changes needed to "man.c":

1) The default value of "roff_opt" is "-rF0" and not an empty value.  Plus a
comment about the reason.

2) Adding an explanation to the manual, saying what the default value is and
why.

  In the meantime an user can define "MANROFFOPT='-rF0'" or even
"MANROFFOPT='-rF1'" to get the list according to the "IX" macro.

  My statement ("indeed it can't") in an earlier e-mail of mine about:

And "man" is not used to get these index entries, indeed it can't.

  is thus wrong.

> -- 
> Russ Allbery (r...@debian.org)   

-- 
Bjarni I. Gislason

Bug#847972: man: Eliminate warnings from '*roff' about the undefined register 'F'

[Russ Allbery]

Bjarni Ingi Gislason  writes:

>   1) The comment is wrong, because the code was changed from what it
> originally was (in my patch in the original bug report; see the last
> line of my input in the first e-mail of this thread).

Well, the comment is correct in that this is what is being attempted.  :)
Apparently it isn't working again.

Your original patch caused problems on HP-UX, which is why it was changed
upstream.  See:

https://rt.cpan.org/Public/Bug/Display.html?id=92979

However, I think all those changes may have not been necessary and only
the missing backslashes were necessary and your original patch was
otherwise fine once those backslashes are added (and possibly more correct
in avoiding warnings).  I'll give that a try.

Apologies for the regression; this is the confluence of two things that
basically no one ever does (enable nroff warnings, and use this obscure
indexing code), so it's essentially never tested.

>   1) 'F' is not a random register in manual pages.

It is, though.  It's a completely random register picked by Tom
Christiansen years and years ago to hang this feature off of because it
wasn't used for anything else.  From the nroff and man-db perspective,
it's just some random user-defined register, not anything special.

Honestly, there's part of me that just wants to drop this entire feature
from Pod::Man, since I'm dubious that anyone actually runs roffitall more
than once every five years or so, or that it's worth maintaining all this
rather opaque code to support.  But I try to be intensely backward
compatible about Pod::Man.

-- 
Russ Allbery (r...@debian.org)   

Bug#847972: man: Eliminate warnings from '*roff' about the undefined register 'F'

[Bjarni Ingi Gislason]

On Mon, Dec 12, 2016 at 06:39:58PM +, Colin Watson wrote:
> Control: reassign -1 perl-modules
> 
> [CCing Russ as upstream for podlators.]
> 
> On Mon, Dec 12, 2016 at 05:07:29PM +, Bjarni Ingi Gislason wrote:
> >* What led up to the situation?
> > 
> >   A warning was issued.
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > 
> >   For example "man perl" with "MAN_KEEP_STDERR=yes"
> 
> That is not sufficient; perhaps you have a "man" alias that enables
> additional warnings.  I spent a little while in some confusion before
> working out that you really meant the following:
> 
>   MAN_KEEP_STDERR=yes man --warnings=w perl >/dev/null
> 

  Sorry, I forgot the other environmental variables:

MANOPT=--no-hyphenation --warnings=w
MANWIDTH=80

  Removing the standard output is not necessary (people want to read the
standard output!), but with pure "/usr/bin/man", one has to scroll the
screen to see clearly, what it output before the manual page.

> >* What was the outcome of this action?
> > 
> > :57: warning: number register `F' not defined
> > 
> >* What outcome did you expect instead?
> > 
> >   No warning, as the macro "IX" is never used.
> 
> Whether the macro "IX" is used is not relevant here.  The comment in the
> page source is slightly misplaced; what the segment of code you quote
> does is define an empty "IX" request, and *then* fiddle with the "F"
> number register.
> 
> >   When a manpage is created from a pod file, using the file "Man.pm", the
> > register 'F' is referenced in the manpage (perl-modules 5.24):
> > 
> > [...]
> > .\" Avoid warning from groff about undefined register 'F'.
> > .de IX
> > ..
> > .if !\nF .nr F 0
> > .if \nF>0 \{\
> > .  
> > [...]
> 
> I can see that that is attempting to avoid a warning.  However, it is
> not quite correct.  It should probably be something like this instead:
> 
>   .if !r F .nr F 0
> 

  1) The comment is wrong, because the code was changed from what it
originally was (in my patch in the original bug report; see the last line of
my input in the first e-mail of this thread).

  2) Not all "man" (*roff) programs understand ".if r ..." (or ".g").

> I think ".if !\nF .nr F 0" is basically a no-op, even when warnings are
> taken into account.  It does arrange that if F was previously
> initialised to a negative number then it will be set to 0 instead (since
> negative numbers are falsy in groff), but I don't think that matters
> much since the subsequent test is "\nF>0" anyway.
> 
> >   To avoid a warning from "groff", the argument "-rF=0" must be added to
> > every call of "*roff" in "man".
> 
> This would not be an even slightly sensible thing to do.  It's not
> appropriate to work around bugs in a particular manual page generator by
> defining random non-built-in registers for it in advance.  That is, the

  1) 'F' is not a random register in manual pages.

> "F" register here is not one that is built into groff, or used by man
> itself, but rather is one used by the podlators tools for its own
> purposes.
> 

  2) The only place, I find in "podlators" showing the use of 'F', is in the
file "pod2man.PL":

"To get index entries on C, turn on the F register, as in:

troff -man -rF1 perl.1"

  And "man" is not used to get these index entries, indeed it can't.

3) The solution ("-rF0" or "-rF=0") is totally independent of any bug
(non-understanding) involving this variable.  Does not need any "correction"
to the original code in "Man.pm", which otherwise then most likely needs the
special variable ".g".  Other implementations of "man" might then issue a
warning, which is to be avoided.

> This suggestion is akin to requesting that "make" should work around
> legitimate warnings about an uninitialised "f" variable in a particular
> C program by implicitly defining f to 0 every time it compiles any C
> program.
> 

  The right use of compilers does issue such warnings.  Then the program
should be corrected.

  "make -e" can use environmental variables to change values in the
"Makefile".

  "man" (man-db) does not provide for defining variables on the command line
nor by using environmental variables, and should not need to.

  If maintainers can't see, whether their changes are correct, a (permanent
(future-proof)) solution outside of their domain is called for.

> Regards,
> 
> -- 
> Colin Watson   [cjwat...@debian.org]

-- 
Bjarni I. Gislason

Bug#847972: man: Eliminate warnings from '*roff' about the undefined register 'F'

[Colin Watson]

Control: reassign -1 perl-modules

[CCing Russ as upstream for podlators.]

On Mon, Dec 12, 2016 at 05:07:29PM +, Bjarni Ingi Gislason wrote:
>* What led up to the situation?
> 
>   A warning was issued.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>   For example "man perl" with "MAN_KEEP_STDERR=yes"

That is not sufficient; perhaps you have a "man" alias that enables
additional warnings.  I spent a little while in some confusion before
working out that you really meant the following:

  MAN_KEEP_STDERR=yes man --warnings=w perl >/dev/null

>* What was the outcome of this action?
> 
> :57: warning: number register `F' not defined
> 
>* What outcome did you expect instead?
> 
>   No warning, as the macro "IX" is never used.

Whether the macro "IX" is used is not relevant here.  The comment in the
page source is slightly misplaced; what the segment of code you quote
does is define an empty "IX" request, and *then* fiddle with the "F"
number register.

>   When a manpage is created from a pod file, using the file "Man.pm", the
> register 'F' is referenced in the manpage (perl-modules 5.24):
> 
> [...]
> .\" Avoid warning from groff about undefined register 'F'.
> .de IX
> ..
> .if !\nF .nr F 0
> .if \nF>0 \{\
> .  
> [...]

I can see that that is attempting to avoid a warning.  However, it is
not quite correct.  It should probably be something like this instead:

  .if !r F .nr F 0

I think ".if !\nF .nr F 0" is basically a no-op, even when warnings are
taken into account.  It does arrange that if F was previously
initialised to a negative number then it will be set to 0 instead (since
negative numbers are falsy in groff), but I don't think that matters
much since the subsequent test is "\nF>0" anyway.

>   To avoid a warning from "groff", the argument "-rF=0" must be added to
> every call of "*roff" in "man".

This would not be an even slightly sensible thing to do.  It's not
appropriate to work around bugs in a particular manual page generator by
defining random non-built-in registers for it in advance.  That is, the
"F" register here is not one that is built into groff, or used by man
itself, but rather is one used by the podlators tools for its own
purposes.

This suggestion is akin to requesting that "make" should work around
legitimate warnings about an uninitialised "f" variable in a particular
C program by implicitly defining f to 0 every time it compiles any C
program.

Regards,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#847972: man: Eliminate warnings from '*roff' about the undefined register 'F'

[Bjarni Ingi Gislason]

Package: man-db
Version: 2.7.5-2
Severity: minor

Dear Maintainer,

   * What led up to the situation?

  A warning was issued.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

  For example "man perl" with "MAN_KEEP_STDERR=yes"

   * What was the outcome of this action?

:57: warning: number register `F' not defined

   * What outcome did you expect instead?

  No warning, as the macro "IX" is never used.

***

  When a manpage is created from a pod file, using the file "Man.pm", the
register 'F' is referenced in the manpage (perl-modules 5.24):

[...]
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.if !\nF .nr F 0
.if \nF>0 \{\
.  
[...]

  To avoid a warning from "groff", the argument "-rF=0" must be added to
every call of "*roff" in "man".

  My original bug report in Debian about "Man.pm" is Bug#674206.


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.36-1 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages man-db depends on:
ii  bsdmainutils   9.0.12
ii  debconf [debconf-2.0]  1.5.59
ii  dpkg   1.18.15
ii  groff-base 1.22.3-8
ii  libc6  2.24-7
ii  libgdbm3   1.8.3-14
ii  libpipeline1   1.4.1-2
ii  zlib1g 1:1.2.8.dfsg-2+b3

man-db recommends no packages.

Versions of packages man-db suggests:
ii  firefox-esr [www-browser]  45.5.1esr-1
ii  groff  1.22.3-8
ii  less   481-2.1
ii  lynx [www-browser] 2.8.9dev11-1
ii  w3m [www-browser]  0.5.3-33

-- debconf information excluded

-- 
Bjarni I. Gislason