Sorry about the upstream list post. I had replied to a couple posts on that list recently and typed it in out of habit, I guess.
So the options are generally either keep it in $PATH and add docs or move it to /usr/share/doc/? If I were to work on thie docs and submit a patch, how long would you be willing to wait? I might not be able to get to it right away. oldtechaa On Feb 26, 2018 4:48 AM, "intrigeri" <intrig...@debian.org> wrote: > Hi, > > > oldtechaa: > > I see what you mean. I think a suggestion would still be good. > > > As for its usefulness, it can help with the nuances of the Perl binding. > > Some things get bound kind of weirdly, so personally, I use the C API > > reference but when something doesn't work as it should, I use > perli11ndoc. > > The perl-specific examples can be invaluable. > > OK, this makes sense to me. > > > While it's convenient to have it in $PATH, I can see it being a problem, > > especially since having no manpage violates Debian standards, doesn't it? > > The problem is that's true of any executable from what I saw, not just > > those in $PATH. > > The Debian Policy is not specific about this: > https://www.debian.org/doc/debian-policy/#manual-pages > > … but the Lintian check clarifies this with "Each binary in /usr/bin, > /usr/sbin, /bin, /sbin or /usr/games should have a manual page": > https://lintian.debian.org/tags/binary-without-manpage.html > > I don't recall seeing a manpage for a script shipped in > /usr/share/doc/$PACKAGE/examples. > > > Is there any way we can follow standards but keep > > perli11ndoc, even if it's slightly less convenient? > > Sure: write a manpage (e.g. add POD and generate a manpage from it at > build time or similar). > > Cheers, > -- > intrigeri >
