Bug 208216 - makewhatis misses lots of entries
makewhatis misses lots of entries
Product: Fedora
Classification: Fedora
Component: man (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ivana Varekova
Ben Levenson
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-09-26 23:12 EDT by JW
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-27 04:33:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description JW 2006-09-26 23:12:43 EDT
Description of problem:
makewhatis doesnt pick up many manual entries because some entries use more than
one dash in SH line, especially Perl entries generated by Pod::Man etc.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Look at, for example, /usr/share/man/man3/PDL::Dumper.3pm.gz
Actual results:
Omitted from whatis database

Expected results:
Should be included

Additional info:
makewhatis should be changed so that 'match(x, / - /)' becomes 'match(x, / --* /)'.
Also, many manual entries (well, only SDL manually entries) omit a space before
the dash.

Wouldn't it be better if makewhatis was a Perl script?  Would be a lot more
maintainable, and more accurate.
Comment 1 Ivana Varekova 2006-10-24 05:09:02 EDT
Fixed in man-1.6d-2.
Comment 2 JW 2006-10-24 06:24:13 EDT
Not fixed!

I have checked with man-1.6d and the makewhatis is more-or-less unchanged from 1.6c.
In fact it still has the "match(x, / - /) in it.

So in what way has it become "fixed in 1.6d" when it doesn't in actual fact
appear to have been fixed at all?

Can I also suggest that when makewhatis is running, and it encounters a file for
which no database entry can be determined, that it optionally lists the file on
standard error.  At the moment there is a "-v" option but all it does is lamely
advise "about to enter ...".

Otherwise long periods of time will elapse with database entries never being
made and with no user or maintainer being aware of what is being missed.

Surely that isn't something too difficult to arrange?

Comment 3 Ivana Varekova 2006-10-24 06:34:39 EDT
Please which version of man do you have (man-1.6d-1 is affected by this bug - it
is fixed in man-1.6d-2)?
Comment 4 JW 2006-10-24 07:58:26 EDT
There is no man-1.6d-2 on local mirror, only 1.6d-1.1.

So how can person who opened bug verify that bug is fixed if the modified source
isn't available?  Wouldn't it make more sense to wait until modified open source
(GPL) software is make public before closing the bug?

After all, there are people like myself who freely give of their time to
discover bugs, and sometimes the fixes, and even to test again.  When a bug gets
closed we are supposed to be able to check, and/or install the fixed software,
but we cannot do that if the fixed software isn't available.

So what happens next?  Wait a couple of weeks for the updated rpm before testing
it?  No, I'm not likely to do that. I will just keep using my own patch, then
wait until next upgrade (could be a year away), and then get surprised that the
bug still exists?

Fix bug, release software, close bug report.

And also just recently have been getting a lot of bug reports automatically
(lazily) closed on account that they "might" be fixed (presumably accidentally)
in FC5. So the onus is put back on bug reporter to retest, reopen bug, because
nobody else can be bothered.  As a result I treat bug closures as extremely
suspicious because in practice they hardly ever seem to get fixed.

Comment 5 Ivana Varekova 2006-10-27 04:33:22 EDT
 i386 version of man-1.6d-2 is in 

 if you need another version you can find it in 

If this bug affects man-1.6d-2 (or higher version), please reopen this bug.

Note You need to log in before you can comment on or make changes to this bug.