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
