Package: devscripts
Version: 2.25.14
Severity: wishlist
X-Debbugs-Cc: [email protected]
devscripts currently depends on sopv | gpgv, where sopv is a purely
virtual package. This means that an unpredictable implementation of the
sopv interface gets chosen. When I tried
$ podman run --rm -it debian:trixie-slim
# apt update
# apt upgrade
# apt install --no-install-recommends devscripts
it chose to install sopv-gpgv and gpgv, but if I instead end with
# apt install devscripts
it chooses to install both gpgv and sq (possibly because dpkg-dev
Recommends those).
Similarly, on test systems for a Debian 13 derivative, I've variously
ended up with sopv-gpgv or rsopv, depending whether I'm upgrading an
existing installation or creating a new one.
Compare with dpkg-dev, which Recommends concrete packages (sqop, sqopv)
in preference to a similar virtual package (sopv), so that users who
don't know what they want will predictably receive the implementation
that is recommended by the dpkg-dev maintainer.
I'm unsure of the benefits and drawbacks of rsopv vs. sqopv. I know that
gpgv has some semantics that are unfortunate for the authenticity check
use-case, like assuming that an unverifiable signature is a serious
problem even if it's accompanied by a valid, verifiable signature.
Can someone (perhaps Daniel) recommend a sopv implementation that is a
good choice for someone who doesn't know much about the finer points of
PGP verification, and just wants something not too large that will check
signatures "correctly"?
I think it would be better for system reproducibility if either
devscripts had a Depends on some-concrete-package | sopv | gpgv, or
devscripts had a Depends on default-sopv | sopv | gpgv, where
default-sopv is either a metapackage that Depends on a recommended sopv
implementation (like default-jdk), or a virtual package that is provided
by exactly one binary package per architecture (like
default-mta and default-logind). The approach where each virtual package
FOO has an accompanying virtual package default-FOO with at most one
implementation seems to be a popular one in recently-implemented
alternatives sets, and it doesn't require trips through NEW.
smcv
