Skip to main content

Ugh, the maintainer of the Debian bcachefs-tools package just orphaned it because its Rust dependencies are moving too fast. jonathancarter.org/2024/08/29/…

So, I need to be careful not to cause that same problem in AccessKit, especially if my current (draft) merge request to use AccessKit in GTK 4 (via the C API) is finished and accepted.

in reply to Matt Campbell

karolherbst 🐧 🦀
karolherbst 🐧 🦀
• •
yeah.. this is the main reason why with #rusticl my policy basically is "I use at most whatever FireFox ESR needs", because FireFox ESR is something every distro has to build and package unless they want to risk an insecure web browser.
#Rusticl
in reply to Matt Campbell

Guido Günther
Guido Günther
• •
can the versions used for gtk4-rs be a sensible baseline? That isn't easy to package for Debian either but so far Debian's Rust maintainers always got it in.
in reply to Matt Campbell

Tobias Hunger
Tobias Hunger
• •

my impression is that it is more that the rust dependency handling is incompatible with how Debian wants to handle dependencies. Note that this is true for go, JS, ... just as well.

In the bcachefs case they built against *newer* dependencies than those the tool had set in their Cargo.toml.

I doubt you need to worry with accesskit: Debian will pick a version and never update that again anyway.

in reply to Tobias Hunger

Matt Campbell
Matt Campbell
• •
@hunger I probably do still need to be careful to minimize AccessKit's own dependencies, especially dependencies on pre-1.0 packages, so we don't have the situation where AccessKit depends on 0.x but Debian has foo 0.y (or 0.w).
@Tobias Hunger
in reply to Matt Campbell

Tobias Hunger
Tobias Hunger
• •

Keep the MSRV low, that is about as much as you can do. At least the rustc the distros pick might still work then.

Distribution will force whichever version of dependencies they picked anyway... whether or not that causes the whole thing to crash or not.

I started to use `cargo install --locked` to make sure to get the binaries the devs tested and not some random crap mutilated by some distribution packager with no clue about rust or programming.

in reply to Matt Campbell

lonjil
lonjil
• •
no he didn't. The version bcachefs-tools that has been shipping for 2 years in Debian stable is broken. Straight up does not work. There was a bug in bindgen 0.66 that makes it not work. So bcachefs first vendored a fixed version, and then updated to 0.69 which was fixed. The Debian maintainer decided to compile with 0.66 anyway, and didn't even test to see if it would work.
⇧