search

kpcyrd / cargo-debstatus

cargo-tree for Debian packaging
https://crates.io/crates/cargo-debstatus
Apache License 2.0
27 stars 9 forks source link

cargo-debstatus fails to find binary packages not built from a `rust-*` source package #44

Open NoisyCoil opened 2 months ago

NoisyCoil commented 2 months ago

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.

jamessan commented 2 months ago

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.

NoisyCoil commented 2 months ago

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.