Re: Rust policy for bcachefs-tools in Debian
On Sun, Sep 14, 2025, at 7:04 PM, Kent Overstreet wrote:
> Hi all, we're looking at getting bcachefs-tools back into Debian (we
> just re-opened an ITP). Was just speaking with you guys on IRC, where
> the possibility of a team meeting was raised, and I was directed to this
> list.
>
> (Thank you capitol; when the previous efforts were happening I had no
> luck with getting connected to the right people, fingers crossed this
> time :).
>
> Background: bcachefs-tools is a mixed C/Rust package, and the dependency
> unbundling requirements are particularly problematic for us. I don't
> think it's realistically possible to ship and support without at least a
> partial exemption.
>
> Rational:
> - It's a critical system package (bugs in this package will cause your
> system to fail to boot), so the testability/maintainability issues
> that unbundling causes have a much bigger impact. As far as I know,
> bcachefs-tools is the first package with this level of criticality to
> make use of Rust.
I'd actually say thin-provisioning-tools is in a similar boat (bugs there
can also cause boots to fail, or cause storage-level corruption). It seems
to be packaged without vendoring/bundling.
> - To make matters worse, it's mixed C/Rust; that means we have lots of
> FFI, and that's a particularly sensitive area (very high potential for
> bugs that won't be caught by the compiler compared to typical Rust
> code).
Point taken - although I think this can also be solved by being careful
around bindgen updates, e.g., checking with upstream whether you did
any changes when upgrading upstream, or pro-actively asking if you
haven't already, communicating potential upgrade blockers downstream in
case you know about them, etc.
> [..]
>
> There's two specific reasons that unbundling is problematic:
> - Swapping out dependencies means the entire package needs to be
> retested. Retesting with the full test suite absolutely has to happen
> for bindgen changes - like I mentioned, FFI is just too sensitive.
> Other Rust dependencies are less sensitive, but given that (even in
> Rust) semantic versioning is a promise with no actual verification,
> we'd want those retested too. Consider the possibility of a clap
> version change that subtly changes option parsing; it's easy to say
> "that would never happen", but as a filesystem developer, I've seen
> and had to debug lots of things that never should have happened :)
We try to run upstream testsuites as part of Debian's CI as well, for
Rust packages this normally means re-running it for any upload of a
dependency (dev-dependencies and rustc/cargo itself included). This
catches a lot of related regressions.
> Given the already high cost of testing and the size of our test suite,
> testing overhead is not something I want to add to. Cargo's locking of
> dependency versions solves a lot of problems for us.
Yes. Locking is fine upstream, but it just doesn't mesh well with how
(regular) distros operate.
> - The other issue that came up before is: for a critical system package,
> we absolutely need to be able to get out hotfixes in a timely manner
> (just like e.g. the kernel).
The solution for that is having stable branches, and backporting important
fixes to those branches in a minimal fashion. Then for Debian stable, we
can package the latest (at the time of the freeze) such stable version,
instead of the latest and greatest.
> This was the major issue that led to bcachefs-tools being orphaned in
> Debian the last time around, when conflict over dependency unbundling
> led to us not being able to ship out a bugfix for mount option
> parsing. (The bug was fixed upstream in a matter of days, and AFAIK no
> one on other distributions was affected). Discussions and resolving
> the issue got sidetracked by "well, it's experimental, it's fine if we
> break this" - so I have to reiterate that it's upstream's policy that
> supporting users and making sure they have a working filesystem comes
> first. It's my policy that the experimental label is simply a warning
> to users that they may run into issues that we haven't discovered yet,
> we still strive to deliver the same level of support (triaging and
> quickly responding to bug reports) that any other filesystem would,
> and having our priorities in the right place from the start is
> critical to shipping a bulletproof, reliable, trustworthy filesystem.
I was not around for that, so can't really add anything.
> So, that's things from my end, and why I'm asking for an exception to
> the unbundling requirements. I'd like to hear things from your side, and
> see what we can do to address any issues this might cause on the Debian
> side. I'm aware of concerns over security updates; Fedora folks also
> raised build server overhead when we had this discussion with them. Like
> I mentioned we never managed to raise this discussion to the appropriate
> places in the past, so if there's other issues at play I'm looking to be
> educated :)
There's a lot of people/teams you'd need to convince in order to get such
an exception:
- ftpmasters (since they'd likely reject your package for containing a ton
of embedded code copies from other projects/packages already in Debian)
- release team (both the part responsible for testing, and the part
responsible for stable - they have the say of what ends up in the next
stable, and how non-security updates are handled there)
- security team (for obvious reasons, they dislike code copies)
- and of course the people packaging/sponsoring your packages, which
might be the Rust team, or some other DDs
There aren't many packages that have such an exception at the moment for
a reason[0]. FWIW, Canonical decided to tackle the static linking issue
differently than Debian, so Ubuntu's main archive vendors everything
Rust, so you'll likely not have an issue there if you convince their
developers to ship bcachefs-tools as part of main.
I do understand that there is a sort of chicken and egg problem here as
well - ideally, you would provide stable branches/releases upstream that
could alleviate some concerns. But those only make sense to you most
likely if you know you can package it in a regular fashion.
Debian Fast Track[1] might be another option - you'd "only" need to
convince ftpmasters and file an RC bug eternally keeping your package
out of testing and thus stable.
Fabian
0: with Rust involved, AFAIR but potentially incomplete:
- rustc (because it would be unmanageable in practice),
- chromium and firefox(-esr) because of security updates and extensive
dependency vetting upstream
- librsvg (like Matthias noted, should/could likely be dropped nowadays)
- ..?
1: https://fasttrack.debian.net/
Reply to: