On Mon, 09 Jun 2025 at 10:21:34 -0400, Daniel Kahn Gillmor wrote:
On Sat 2025-06-07 14:52:33 +0100, Simon McVittie wrote:
OK, in that case:
sqopv | sopv-gpgv | sopv
As i understand it, the point of this recommendation is to have a
predictable sopv choice (sopv-gpgv) for platforms that can't build
sqopv (e.g., due to lack of Rust)
Yes. On release architectures and other rusty platforms, sqopv is the
preferred choice, it gets installed, success. On non-rusty ports, sqopv
is unsatisfiable, so apt tries sopv-gpgv, which gets installed, success.
The non-default sopv option (which is non-deterministic because it has
multiple implementations) is only reached if an implementation happens
to be installed already.
(If you only care about predictability on release architectures and other
rusty platforms, then the sopv-gpgv option can be omitted. I am,
personally, not very interested in -ports, but I try to be nice to them
when it's this easy to do so.)
The other nice thing about this approach is that we could drop drop all
code that invokes gpgv directly from devscripts
As a change for forky, great, please do that. As a change for trixie, in
the release team's place I'm not sure that I'd accept that code-deletion
during hard freeze (but I'm not the release team and perhaps my guess at
their preference is wrong).
or perhaps
sqopv | sopv-gpgv | sopv | gpgv
This one i'm not as convinced by. If gpgv is already installed,
then installing devscripts (on a platform with or without rust) won't
bother installing any of the sopv variants, right?
Yes, I think so. This is the more conservative of my two suggestions
quoted in this message, matching current behaviour more closely than my
other suggestion; but if you're unhappy with the quality of the
(non-sopv-) gpgv code path, then you should prefer my other suggestion
over this one.
smcv
