Package: src:rust-libsqlite3-sys Version: 0.28.0-3 Control: forwarded -1 https://github.com/rusqlite/rusqlite/issues/1216 Control: affects -1 + src:rust-rusqlite
Several of the rusqlite features fail when supplied without including the "modern_sqlite" feature, because they fall back to using pre-shipped legacy bindings for older versions of libsqlite3. failures tend to look like this: > error[E0599]: no method named `set_estimated_rows` found for mutable > reference `&mut IndexInfo` in the current scope > --> src/vtab/array.rs:110:18 > | > 110 | info.set_estimated_rows(100); > | ^^^^^^^^^^^^^^^^^^ help: there is an associated > function with a similar name: `set_estimated_cost` Let me be clear that there are a few wrinkles here: - When Debian strips the embedded copy of libsqlite3 from the libsqlite3-sys crate source, we are also stripping the pre-generated bindings shipped by upstream. This is upstream's "bundled_bindings" feature, which we don't ship in Debian either. - We change "modern_sqlite" in the rusqlite crate to depend instead on libsqlite3-sys's "buildtime_bindgen" feature so that the bindings actually match the version of libsqlite3-dev that is available during build. - However, building or testing rusqlite without any of the above binding choices means that we end up using some of the much older pre-crafted bindings in `libsqlite3-sys/bindgen-bindings/bindgen_3.*.rs`. These definitely *don't* have the features available that the user wants. Here's the list of features that have this kind of problem, edited down from the autopkgtest run on ci.debian.org: librust-rusqlite-dev:array FAIL non-zero exit status 101 librust-rusqlite-dev:csvtab FAIL non-zero exit status 101 librust-rusqlite-dev:release_memory FAIL non-zero exit status 101 librust-rusqlite-dev:series FAIL non-zero exit status 101 librust-rusqlite-dev:unlock_notify FAIL non-zero exit status 101 librust-rusqlite-dev:vtab FAIL non-zero exit status 101 librust-rusqlite-dev:window FAIL non-zero exit status 101 I see four possible ways of dealing with this in debian: a) Mark these 7 autopkgtests in rust-rusqlite as flaky because we know that they fail in this way. Users who want to depend on these features should *also* depend on the "modern_sqlite" or "buildtime_bindgen" features (which do roughly the same thing) b) patch Cargo.toml in rust-rusqlite to make those seven features *also* depend on modern_sqlite c) patch the failing bits of the rust-rusqlite tests so that they are appropriately hidden behind some kind of !cfg feature flag d) strip out the the logic in libsqlite3-sys/build.rs (around line 469) that deals with these PREBUILT_BINDGEN_PATHS and also exclude libsqlite3-sys/bindgen-bindings/bindgen_3.*.rs from the source in the way we're excluding the bundled_bindings stuff. in libsqlite3-sys/Cargo.toml, set: default = ["buildtime_bindgen"] Perhaps some of these four choices can or should actually be done in combination with each other as well. I particularly like the idea that packages built from Debian will all use bindings generated at build time, so that we're not shipping any autogenerated files as part of upstream. It'd be good to have the full toolchain built as close to the libsqlite3 source as possible. Any thoughts about the right way forward for Debian? --dkg PS Additionally, as a separate issue, the --all-features test fails because it tries to build against sqlcipher while generating the bindings using buildtime_bindgen: rust-rusqlite:@ FLAKY non-zero exit status 101 This is because sqlcipher is out of date in debian, see https://bugs.debian.org/1017577 for more details.
signature.asc
Description: PGP signature