Conflict of `libsqlite3-sys` (via `sqlx-sqlite`) with newer `rusqlite` in downstream workspaces

[secana]

Description

When using SeaORM with the sqlx-sqlite feature enabled alongside any crate that depends on a newer rusqlite (e.g. the cargo crate), Cargo fails to resolve dependencies due to a hard conflict on the native links = "sqlite3" crate libsqlite3-sys.

Current versions in the ecosystem have non-overlapping semver requirements:

• sqlx-sqlite (pulled via SeaORM 1.1.16 → sqlx ^0.8.4) requires: libsqlite3-sys ^0.30.1
• rusqlite v0.34.0 (via cargo v0.90.0) requires: libsqlite3-sys ^0.32.0

Because two different versions of a crate declaring links = "sqlite3" cannot coexist and the semver ranges do not overlap, Cargo aborts resolution. This blocks downstream workspaces that need SeaORM with SQLite plus tooling that (directly or indirectly) depends on rusqlite ≥ 0.34.

This issue is a request to bump (or relax via an upstream sqlx bump) the effective libsqlite3-sys requirement in SeaORM’s SQLite stack so it can coexist with the newer rusqlite chain.

Steps to Reproduce

1. Create a new Cargo workspace (or empty project).
2. Add the following Cargo.toml (see “Reproducible Example” below).
3. Run: cargo check
4. Observe dependency resolution failure referencing libsqlite3-sys.

Expected Behavior

SeaORM (with SQLite enabled) and another crate depending on rusqlite ^0.34 can be built together, with a single unified libsqlite3-sys version (≥ 0.32.x) selected.

Actual Behavior

Cargo produces an error:

error: failed to select a version for `libsqlite3-sys`.
  ... required by package `sqlx-sqlite v0.8.5`
  ... which satisfies dependency `sqlx-sqlite = "=0.8.5"` of package `sqlx v0.8.5`
  ... which satisfies dependency `sqlx = "^0.8.4"` of package `sea-orm v1.1.16`
package `libsqlite3-sys` links to the native library `sqlite3`, but it conflicts with a previous package which links to `sqlite3` as well:
package `libsqlite3-sys v0.32.0`
  ... required by package `rusqlite v0.34.0`

Reproduces How Often

Always (deterministic) with the listed version set.

Desired Resolution

Publish a SeaORM release that depends on a sqlx version whose sqlx-sqlite permits or uses libsqlite3-sys >= 0.32 (aligning with current rusqlite).
Alternatively, relax constraints if upstream sqlx has already widened them.

(If such a release already exists, guidance on required feature or version adjustments would be appreciated.)

Reproducible Example

Cargo.toml (minimal):

[package]
name = "seaorm-sqlite-conflict-demo"
version = "0.0.1"
edition = "2021"

[dependencies]
# SeaORM with SQLite enabled
sea-orm = { version = "1.1.16", features = ["sqlx-postgres", "sqlx-sqlite", "runtime-tokio-rustls", "macros"] }

# Pulls rusqlite ^0.34.0 transitively (via cargo -> rusqlite)
cargo = "0.90.0"

Command & output:

$ cargo check
    Updating crates.io index
error: failed to select a version for `libsqlite3-sys`.
  ... required by package `sqlx-sqlite v0.8.5`
  ... which satisfies dependency `sqlx-sqlite = "=0.8.5"` of package `sqlx v0.8.5`
  ... which satisfies dependency `sqlx = "^0.8.4"` of package `sea-orm v1.1.16`
package `libsqlite3-sys` links to the native library `sqlite3`, but it conflicts with a previous package which links to `sqlite3` as well:
package `libsqlite3-sys v0.32.0`
  ... required by package `rusqlite v0.34.0`

Dependency graph snippet:

$ cargo tree -i libsqlite3-sys
libsqlite3-sys v0.30.1
└── sqlx-sqlite v0.8.5
    └── sqlx v0.8.5
        └── sea-orm v1.1.16

libsqlite3-sys v0.32.0
└── rusqlite v0.34.0
    └── cargo v0.90.0

Environment

• SeaORM: 1.1.16
• sqlx (resolved): 0.8.5
• rusqlite: 0.34.0
• OS: Linux x86_64 (repro also expected on other platforms)

Additional Notes

Happy to:

• Test a branch or pre-release that bumps the dependency.
• Provide more detailed logs (CARGO_LOG=cargo::core::resolver=trace) if useful.
• Open a PR if the maintainers prefer an assisted bump (pending sqlx upstream constraints).

Thank you for maintaining SeaORM!

[Huliiiiii]

Sqlx has already fixed this issue, but it hasn’t been released yet. Should we patch it ourselves, or wait for the new sqlx release?

[tyt2y3]

we can wait for sqlx's release

[secana]

Thanks for the fast response. I'll see if I can find out, why the sqlx release is stuck. The issue exists since quite some time. Maybe there is something I can do, to get it resolved.