SDK manpages bad-whatis-entry
See original GitHub issueDescribe the bug
Manpages for multi-level commands for dotnet
violate Debian’s lintian rule for use by whatis
and apropos
.
To Reproduce
I’m not sure how to reproduce this directly, but I do know attempting to build 6.0.102 from https://github.com/dotnet/installer making use of debmake
and sbuild
, at the end of a successful build, every man, with exception to dotnet-vstest.1
, and dotnet.1
give a lintian warning of bad-whatis-entry
, as the name for the multi-level commands are space separated, while it is suggested they be separated instead by an underscore, so they can be properly discovered by whatis
and apropos
. As an example, if I am understanding this correctly, for dotnet-add-package.1
, instead of the line \f[C]dotnet add package\f[R]...
, it should be \f[C]dotnet_add_package\f[R]...
.
Further technical details
Issue Analytics
- State:
- Created a year ago
- Comments:19 (8 by maintainers)
Top GitHub Comments
After trying this myself, I found that it wasn’t quite as simple as I thought. The
dsc
file also contains hashes and sizes of the archive files. After manually updating that with the new hash and file size, I was able to run it. The result shows all thebad-whatis-entry
messages gone, with only thegroff-message
remaining, all mostly the same, as well as one new one fordotnet.1.gz
.I’m not sure how much of an issue these are. They all appear to be related to tables possibly being too large for a display. However, with the rather large terminal screen size that I have, I don’t see any issue with the pages. Even when using XTerm in order to get a smaller terminal screen size (as I’m not sure how native terminal can be resized, and, for some reason, I can’t resize QTerminal), it is still legible enough.
Here is the source package, made up of three files. The two
.zip
files are not actually zip files, I just added the extension to it so that it could be uploaded. Thedotnet-sdk-manpages_1.0.0.orig.tar.gz
file contains the manpages from source build 6.0.102 with the patch from the PR applied. Ideally, you would replace that with a file with the same name and same internal directory layout with updated files. I was able to runsbuild
with only these three files by runningsbuild dotnet-sdk-manpages_1.0.0-1.dsc -d unstable
, while already having an sbuild schroot of Debian unstable already set up. Alternatively, you can extract the contents ofdotnet-sdk-manpages_1.0.0.orig.tar.gz
anddotnet-sdk-manpages_1.0.0-1.debian.tar.xz
into the same directory and just runsbuild
from that directory. I’m sure you can also use another build system, such asdebuild
,pbuild
, ordpkg-buildpackage
. If lintian is not automatically run after the build, you can manually run lintian specifying the produced deb package. dotnet-sdk-manpages_1.0.0.orig.tar.gz dotnet-sdk-manpages_1.0.0-1.debian.tar.xz.zip dotnet-sdk-manpages_1.0.0-1.dsc.zip