kpcyrd
cargo-debstatus fails to find binary packages not built from a `rust-*` source package
In order to find packages in Debian, cargo-debstatus queries the UDD using
SELECT version::text FROM sources WHERE source in ($1, $2) AND release='sid';
where $1 and $2 are, respectively, rust-$CRATE and rust-$CRATE-$VERSION. The assumption that $CRATE, within Debian, is built from a source package named rust-$CRATE (or rust-$CRATE-$VERSION) is however too restrictive, and thus ultimately wrong. While the Rust Team, via debcargo and debcargo-conf, does follow this convention, there are rust packages (and packagers) in Debian which do not.
Two examples of this are the usvg and resvg crates, whose Debian binary packages librust-usvg-dev, librust-resvg-dev, usvg and resvg are in unstable (albeit removed from testing for reasons), but are listed as absent from Debian* by cargo-debstatus. They were built from src:resvg, so the above query does not find them. On the other hand, the query
SELECT version::text FROM sources WHERE source = 'resvg' AND release='sid';
does find the source package.
One possible mitigation could be issuing a preliminary query for
SELECT version::text FROM packages WHERE package in ($1, $2) AND release='sid';
where $1 and $2 are, respectively librust-$CRATE-dev and librust-$CRATE-$VERSION-dev, and declaring the package as found (i.e. without issuing the src:rust-* query) if it matches. Doing so may slow things down for packages which do not build a library, but these are the vast minority. On the other hand, it would find rust library packages which are provided outside of debcargo-conf and not built fro a rust-* source package: regardless of who's building the package, the librust-$CRATE-dev convention is much more solid than the src:rust-* one. Actually, the former is more than a convention, since every rust packager knows that their rust library dependencies all have the form librust-$CRATE-dev.
* Actually, they are now listed as NEW, because I partly relied on cargo debstatus to learn what dependencies I had to package for broot, and didn't realize those were already in unstable. This is what led me to open this bug.
I think moving from a source-centric view to a binary-centric view makes sense. It's something I've been thinking of for a long time, but haven't had the chance to work on.
The reason why I said one could issue a preliminary query is because moving entirely to searching binaries could be equally bad. It would only work for rust library packages and ignore packaged binaries. On the other hand, first looking for librust-$CRATE-dev, and only then (if the former is not found) for src:rust-$CRATE could be a good strategy since it would cover everything managed by debcargo-conf + every library that's not but which is packaged in a way that it can be used as a build dependency. What would be left out then is binaries not managed by debcargo-conf whose source package is not named rust-$CRATE. Not ideal, but also probably not the kind of packages you'd look for using cargo debstatus. The name of these packages (either source or binary) is not sufficient to tell if they are Rust packages anyway.
I'm happy to merge a patch for this 👍 (or one of the other people with commit access merging one)
@kpcyrd would you also be open to a PR which mocks up SQL accesses in tests? There are a couple of disabled tests which I would intuitively reuse for such a feature, but I think it would be better to have them not disabled. I would introduce a trait to abstract away the SQL client and replace it by a stub during tests. The cache dir would be replaced by a temporary directory too.
I've made a patch for this, but to make testing easier I found it useful to first do the stubbing mentioned above: https://github.com/kpcyrd/cargo-debstatus/pull/56. Happy to submit the patch as a PR once #56 is reviewed :)