On Thu, Dec 07, 2023 at 01:02:58AM +0000, Peter Green wrote: > On the one hand I'm not at all convinced this bug is rc, on the other > hand I don't think shipping a four year old version of env-logger > in the next release of Debian is a great idea. > > So I decided to look at the reverse dependencies, I found three > > safe-vdash - this is a Jonas package, the dependency on rust-env-logger-0.7 > seems bogus, I filed a bug. > rust-tracing-log - the new version no longer depends on env-logger, I updated > it along with it's reverse dependency tracing-subscriber. > rspotify - this package is long term broken, noctis expressed an interest in > fixing it back in January but I don't know what if-any progress he has made > since then.
(as always!) thanks for the analysis above. I agree that reducing the env_logger versions in testing is a good idea in any case. the question is whether we want to drop the unversioned provides in semver-suffixed packages altogether in debcargo - IIRC debcargo itself would never generate an unversioned dependency in d/control except if Cargo.toml itself has an unversioned dependency, which is not possible for crates on crates.io. that would only leave manually generated dependencies, or patched crates with very strong relaxation. and even so, the normal flow for semver-suffix packages would work just fine: - fork semver suffix package, upload to NEW/experimental - wait for NEW processing - bump regular package, upload both to unstable and any package that uses an unversioned dependency would stay on the non-suffixed package providing/containing the latest packaged version, while anything depending on the old semantic version would switch to the suffixed package. the only thing that wouldn't work anymore is having a versioned dep on the unversioned package where the version constraint would only be satisfied by the suffixed package. e.g., librust-env-logger-dev (<= 0.8)
