what your Cargo.toml looks like?
[package]
name = "sriblock_core_root"
version = "0.1.0"
edition = "2021"
[dependencies]
sha2 = "0.10"
chrono = { version = "0.4", features = ["serde"] }
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
k256 = { version = "0.13", features = ["ecdsa", "pem"] }
rand_core = { version = "0.6", features = ["std"] }
base64 = "0.22"
hex = "0.4"
uuid = { version = "1.17", features = ["v4"] }
Networking and API Server Dependencies
tokio = { version = "1", features = ["full"] } # Asynchronous runtime for network operations
reqwest = { version = "0.11", features = ["json"] } # HTTP client for sending requests and its "json" feature
axum = { version = "0.7", features = ["macros", "json"] } # Web framework for building APIs
tower = "0.4" # Utilities for services (Axum depends on Tower)
tower-http = { version = "0.5", features = ["trace"] } # HTTP specific layers like tracing (logging)
tracing = "0.1" # For logging, integrated with tokio/axum
tracing-subscriber = { version = "0.3", features = ["env-filter"] } # For configuring logging
To unify hyper version for all dependencies (Crucial for fixing hyper error if it occurs)
[patch.crates-io]
hyper = { version = "0.14.32", features = ["full"] }
It is already unified inside one major version (or, since it's 0.x, inside minor version) and can't ever be unified across several such versions without patching whatever crate depends on it.
if I understand it correctly, you are trying to do something like the npm's overrides feature? but as far as I know, cargo doesn't support such feature.
the patch section of cargo is to replace a registry's source for the specified crates. it only affects your local builds, mainly used for local development purpose, and it is NOT published to crates.io.
you are mis-using cargo's patch feature.
as @Cerber-Ursi said, dependencies of the same major version is automatically unified by cargo, and so is the feature set. you should add the package as a normal dependency, then cargo will pick the proper version and features for you.
note, if multiple semver incompatible versions of the same package is used transitively, cargo will NOT unifiy them, but instead build them separately. this is by design, this is NOT a bug of cargo.
having multiple major versions of same package should not be a problem in general. but in case you did encounter such issues, it should not be solved by overriding the version.
if possible, first try upgrade (or sometimes, downgrade) some of your direct dependencies. if this can't be done, you can try to patch (and maybe also vendor) the source code of the intermediate dependencies' locally.
For future reference, avoid screenshots. Instead, format contents of files and terminal output as described in Forum Code Formatting and Syntax Highlighting