[Pkg-rust-maintainers] Bug#1093053: sqopv, sqop: Please provide slave link alternatives for sopv man page
Guillem Jover
guillem at debian.org
Tue Feb 4 11:52:21 GMT 2025
Hi!
On Mon, 2025-02-03 at 19:40:56 -0500, Daniel Kahn Gillmor wrote:
> 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.
Ah, good point!
> I'm not sure what the right way to resolve this is.
I think ideally a program that provides the entire SOP set, and does
not provide a dedicated CLI for the SOPV set, would in addition
provide a man page for the SOPV set (thinking about gosop here for
example, perhaps pgpainless-cli too?).
The problem then is for projects that provide both the SOP and SOPV
sets, and those get packaged independently. Because then if the SOP
needs to provide sopv.1 and sop.1 man pages that would conflict with
the SOPV package. Hmmm.
> 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
I also thought about this initially, but I think the problem is that
what one implements from SOP might be different, so it perhaps might
end up being more confusing than helpful? Or what about the versions
we have discussed in the past? I mean that sopv-doc could perhaps also
provide the spec itself, and then stuff like sopv-1.0.1 sopv-1.1.1,
and specific packages could add as slave links the desired version,
but I'm not sure whether you'd be happy with this either (given your
previous push back for simplicity :D).
> Any thought about this approach, or any other suggestions?
The other thing that comes to mind is, do we need to make it possible
to co-install the sop and sopv variants of the same implementation? I
mean sop should be able to cover for sopv, no?
But I'm not sure whether the above would simplify things or make them
more complex or confusing, TBH.
Thanks,
Guillem
More information about the Pkg-rust-maintainers
mailing list