Re: CVS commit: pkgsrc/misc/py-anita

[Greg Troxel <gdt%lexort.com@localhost>]

Andreas Gustafsson <gson%NetBSD.org@localhost> writes:

> Greg Troxel wrote:
>> Documentation in MESSAGE is a bug, per the pkgsrc guide.  It's true that
>> there are historical cases of that remaining.
>
> My point about audio/abcde was not that documents its runtime
> dependecies specifically in MESSAGE (as opposed to DESCR or the
> man page), but that it does not make them package options.

OK - that's a fair point.

We don't really have a settled approach about this.  Or really we mostly
do, and having documented but not pkgsrc-required run-time dependencies
is irregular.  Generally, when one installs a package, the expectation
is that it installs what is needed to work.

In some cases, it gets more complicated.  Things might need a database
server, in which case they would link against the database client libs,
but not depend on the server, because that could be on a separate
machine.  Most cases like this have full administration manuals from
upstream.

In general, and when not too painful, I think it's nice to have a
package be able to depend on what it requires.  That lets people use the
package system to manage dependencies, and to have things that are
really dependencies rather than wanted packages (this is the oddly-named
"keepable" package concept in pkgin).  If you install qemu just for
anita, and later uninstall anita, then "pkgin ar" should remove qemu.
But if you installed it for some other reason also, it shouldn't.  This
is an argument for expressing dependencies in options, not an argument
against documentation.

In the specific case of abcde, the man page says it needs a lot of
"backend tools".  As far as I can tell, encoders are left out of
dependencies, and the rest are included.  I can see why, but it feels a
bit off from upstream's expectations.  Interestingly, Debian's
dependencies for abcde are:

  Depends: cd-discid, wget, cdparanoia | icedax, vorbis-tools (>= 1.0beta4-1) | lame | flac | speex | musepack-tools | opus-tools, libmusicbrainz-discid-perl, libwebservice-musicbrainz-perl (>= 
1.0.4-1.1), sensible-utils



I have never meant to say "because there is options.mk, there's no need
for documentation".  I only meant that having options makes the exact
packages clear, and it enables people who build packages to set the
options so that they can use pkgsrc to track these dependencies.  Aside
from this discussion, I think this practice has not caused problems.

Certainly, documentation for a program should explain what is needed.
For a program where it is reasonable for a packaging system to omit
dependencies on the grounds they are runtime only, the program's
documentation (provided by the program) should discuss that additional
things must be installed, and explain how to choose.

It's reasonable to note in DESCR what isn't in the package when the
normal conventions would suggest it's there.    It really shouldn't be
expanded to anything more than the briefest mention, as that goes beyond
"describing what's in the package".

While there are probably a few more, I think this situation is quite
rare.  But overall, I think for this kind situation

  documentation is necessary (such as man page, installed README)

  options are fine if somebody wants to do that


Does that seem reasonable to you?