On Guillem Jover wrote: > This package provides sopv alternatives for the sqopv program, but it > does not include in the alternative the manual page. Please add them > as slave links, so that we can do «man sopv» regardless of the > implementation selected.
I thought about this when i was providing the alternatives directives
for these packages, but i hesitated. I noticed that making sqop.1 a
slave link for sopv.1 would result in a "man sopv" that describes many
subcommands that are not formally part of sopv.
For example, if "man sopv" shows a manual page that suggests "sopv sign"
is a thing, that would be misleading, if not actively harmful for the
users, who might depend on it and then when they discover that other
sopv's (including sqopv!) don't have a "sopv sign" they would be
disappointed.
I'm not sure what the right way to resolve this is.
One approach would be to ship a sopv.1 as an entirely separate package
(sopv-doc?)
And then any package that Provides: sopv could also Recommends: sopv-doc
Any thought about this approach, or any other suggestions?
--dkg
signature.asc
Description: PGP signature
