Sorry I emailed your address, Gmail likes to do that. Original email below.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.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. Is there any way we can follow standards but keep perli11ndoc, even if it's slightly less convenient?oldtechaaOn Feb 25, 2018 8:12 AM, "intrigeri" <intrigeri debian org> wrote:Hi,
oldtechaa:> Package: libglib-object-introspection-pLet's keep in mind that libglib-object-introspection-perl
> Version: 0.042-1
> Severity: normal
> Dear Maintainer,
> The utility perli11ndoc in libglib-object-introspection-perl depends on
> libxml-libxml-perl. This should be either a package dependency or recommendation for
> those who intend to use perli11ndoc.erl is needed at
runtime by any Perl program that uses GObject introspection.
Given Debian installs Recommends by default and perli11ndoc is an
add-on that's only useful for developers, I don't think we should pull
libxml-libxml-perl on all systems that happen to have a Perl program
that uses GObject introspection. So IMO it should be "Suggests:
libxml-libxml-perl" at best, with a note in README.Debian about this.
To be honest I've been hesitating about shipping perli11ndoc in $PATH
at all: it lacks a manpage, has additional dependencies, and I'm not
quite sure what it gives us that Devhelp does not (while Devhelp
displays much more complete and better structured documentation).
So perhaps shipping this program under
/usr/share/doc/libglib-object-introspection-perl/examples/
would be more suitable. What do you think?
Cheers,
--
intrigeri