On Mon, 02 Jun 2025 at 12:40:17 -0400, Daniel Kahn Gillmor wrote:
I don't think this is quite right, holger, since devscripts doesn't know
how to handle either "sqv" or "gpgv-sq".
If devscripts only knows how to operate a sopv implementation or, as a
special case, gpgv, then yes it should only list sopv implementations
and gpgv in this list of alternatives.
Ideally, devscripts wouldn't be the package to make this decision
Sure, but unfortunately we don't live in an ideal world, and we're
unlikely to arrive in one before the trixie release!
In the long run, it would be nice to not hard-code this specific
preference list, and just let the system default OpenPGP verifier work
as planned.
What is "the system default OpenPGP verifier"? Is that a
yet-to-be-designed mechanism, or some sort of default-sopv virtual
package or metapackage, or what?
For OpenPGP signature verification, prefer specific implementations of
the Stateless OpenPGP Verification subset rather than just the generic
"sopv" variant.
...
+ sqopv | rsopv | gosop | sopv | gpgv,
Thanks, this answers the question I wanted to ask on behalf of my Debian
derivative: "which sopv implementation should we prefer to work around
this?" -> sqopv.
But, is there a reason why the less-preferred (non-sqopv)
implementations need to be listed explicitly? If they can be dropped
from the or-group, then that would mitigate your maintenance concerns.
sqopv seems to exist on all release architectures, and on all -ports
architectures that have a working rustc/cargo. Even if we're assuming
that non-Rust -ports architectures are important, the the minimum to get
a predictable installation would be to list some real package that
exists on those architectures as higher-preference than (i.e. before)
the sopv virtual package, like maybe:
sqopv # real package, but not on all architectures
| gpgv # real package, portable fallback
| sopv # virtual package
which I believe would result in this result:
- if the user already has either a sopv implementation or gpgv installed,
then the dependency is satisfied, so do nothing;
- else if this is a Rusty architecture, install sqopv (most-preferred
alternative);
- else install gpgv (less-preferred alternative)
- and in principle if gpgv was somehow unavailable, fall back to
installing any sopv implementation (least-preferred alternative), but
in practice gpgv seems to have architecture coverage equal to or wider
than any sopv implementation
sqopv has wider architecture coverage than rsopv, so listing rsopv
doesn't seem like it adds value: on any architecture where rsopv is
available, you're asking apt to prefer sqopv anyway.
Similarly sqopv has wider architecture coverage than gosop (which FTBFS
on most -ports architectures) so listing gosop doesn't seem like it adds
value.
Other implemetations are very close to implementing
sopv (e.g. pgpainless-cli, see
https://github.com/pgpainless/pgpainless/issues/445 ) and it would be
a shame to have to maintain this list in devscripts's dependency list
over the the long term.
I agree, but this could be mitigated by not listing implementations that
won't have a practical effect on what gets installed.
If I understand apt correctly, what I'm asking for is effectively: on
every architecture, there is a real (non-virtual) package listed as
more-preferred than the sopv virtual package. That makes the choice of
package to install (mostly) predictable.
If we can cut the or-group down to "sqopv | gpgv | sopv", then I think the
only maintenance that will be needed is: if our most-preferred sopv
implementation changes, such that instead of sqopv you would prefer new
installations to get my-new-sopv, then devscripts will need changing to
replace the or-group with "my-new-sopv | gpgv | sopv".
(Or, perhaps more realistically, if we get a default-sopv metapackage or
virtual package in forky, then that would replace sqopv.)
smcv
