Hey Guillem-- Thanks for thinking this through with me!
On Tue 2025-02-04 12:52:21 +0100, Guillem Jover wrote: > 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. Right, that gets a bit tricky. In this scenario perhaps it would be something like each package that covers the SOPV subset in *addition* to other parts parts of sopv would also ship a foo-sopv.1, and then we could connect that to /etc/alternatives as sopv.1. So for example, we'd ask upstreams to produce a sopv-only manpage, like: sqop-sopv.1 (in addition to sqop.1 and sqopv.1) rsop-sopv.1 (in addition to rsop.1 and rsopv.1) gosop-sopv.1 (in addition to gosop.1) pgpainless-cli-sopv.1 (in addition to pgpainless-cli.1) I worry that this is a bunch of duplicative effort we'd be asking for upstreams, and i want upstreams to focus on the implementation. I feel like we're pushing them already to provide manpages in the first place (as usual, sigh). I don't want to create more busywork. >> 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? Let's keep our thinking about full-blown sop separate from sopv for now; we don't have /etc/alternatives for sop yet, in part because it is still growing and we don't have the minimized versioning there that sopv has. > 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). Yeah, i'm still leaning toward simple if i can :) Let's not solve the more complex and rare problems if the common problems have simple solutions for now. > 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? This is possible today, and i don't think it's a problem at all (i've got both sqop and sqopv installed as we speak). Maybe i'm misunderstanding your question? In talking this over, i think the fact that sopv has a simple definition is encouraging me to go the sopv-doc route. We can write the sopv.1 documentation centrally, which describes the specific standard that sopv implementations are expected to meet, including the versioning information. If some implementation only implements sopv 1.0, even though the manpage sopv.1 documents both sopv 1.0 and sopv 1.1, i don't think that's a problem. A reasonable place to develop that generic sopv manpage would be the SOP specification repo itself, so i've opened a issue there: https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/132 Regards, --dkg
signature.asc
Description: PGP signature
