Re: Rust policy for bcachefs-tools in Debian
On Fri, Sep 19, 2025 at 04:32:15PM +0200, Fabian Grünbichler wrote:
> 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.
Bindgen was _exactly_ the package where things went horribly awry last
time! :)
Telling the package maintainer up front "_please_ be careful and don't
touch that one, it's particularly sensitive" wasn't sufficient to avoid
issues, and it was a painful experience for all involved.
> 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.
Our test suite is really heavy and not something you'd likely to be able
to pull into your CI, and we have our own dashboards and automation.
IOW, we need to be working together on testing/QA.
> > - 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.
Where are you going to find an engineer qualified to do filesystem
backports, though? They do not grow on trees :)
We will be doing backports, but at this time it's too early to say if
two years of backports would even be feasible - and I don't think it'd
be the best way to deliver the most stable/reliable experience to users.
I need to wait another six months before I commit to anything here. On
the plus side, based on the overall trajectory of stabilization I think
we will have significantly less backporting to do than other filesystems
(I push very very hard on QA and hardening, because view that as having
a much bigger payoff per engineer/hour than catching things later and
doing backports).
> 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)
Dependency vetting upstream is a very good point to bring up, thanks.
That's an area where I think we could be doing better and would be more
than happy to collaborate and work with you guys.
I could see us possibly agreeing to a policy where we only vendor
dependencies that Debian is already packaging (and thus vetting). Or
even better - something that's been on my wishlist - would be a more
"community based" approach to vetting, set up as a web of trust.
I don't follow the Rust world enough to know - are there any projects
tackling the dependency-trust problem? Or does Debian have anything
formal for this, besides "if we've packed it we've vetted it"?
Reply to: