Re: Rust policy for bcachefs-tools in Debian
On Sun, Sep 14, 2025 at 07:33:56PM +0200, Matthias Geiger wrote:
> On Sun, 14 Sep 2025 19:04, Kent Overstreet <kent.overstreet@linux.dev> 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.
> >
> > [...]
> >
> > 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 :)
> >
> Hi Kent,
>
> if you're talking about crates.io vendoring, that's kinda unwanted in
> Debian. Multiple reasons come to mind:
Yes, that's what I'm talking about, for all the reasons I just outlined.
It's led to real issues in the past, which have been severe enough that
we'd probably ship as a PPA if we can't get at least a partial
exception. Which is obviously not ideal :)
> - Security issues: If they occur the can be easily migitated by a rebuild
> archive-wide for the packaged crates (not when vendored)
For security issues, I think this is a solved problem; there are bots
that watch repositories and notify if there are out of date dependecies
(and I've got these notificiations once or twice in the past).
Also, our current list of dependencies, with the exception of bindgen,
is all pretty small stuff that should raise no particular security
concerns.
I do expect that to change in the near future, as I'm going to be
implementing telemetry (automated reports for failures to mount and
other errors) - that's probably going to be the next big project, and
something that needs to get done before more widespread deployment, I
want hard data on how well it's doing in the wild and to make sure we're
not missing any issues.
That will be in Rust and it'll involve network traffic, and it'll also
be a separate component that won't impact the rest of the system if it
has issues - so I'd be fine with unbundling those dependencies.
But for the components that are critical to the functioning of the
system, this does need real consideration.
> - Duplication: Inevitably crates will needlessly get duplicated (i.e. serde
> 1.0.212 and serde 1.0.100)
I'm not seeing how this is an actual issue, though. Keep in mind Rust
doesn't support dynamic linking for native Rust libraries, so there's no
impact on the user machine.
> - Space: this increases the .debian.tar.xz size by a lot
To give an actual number to this one:
-rw-rw-r-- 1 kent kent 1.3M Sep 14 11:31 /home/kent/bcachefs-tools/bcachefs-tools-1.31.0.tar.zst
-rw-rw-r-- 1 kent kent 23M Sep 14 11:31 /home/kent/bcachefs-tools/bcachefs-tools-vendored-1.31.0.tar.zst
So it's significant - but I wouldn't be the person who'd know how much
the ftpmasters will scream.
Unfortunately the most sensitive dependency (bindgen) is also the
biggest - and that one really is sensitive, since bcachefs hits issues
with types that are both packed and aligned that Rust doesn't handle
well and require workarounds in bindgen. And FFI bugs _really_ suck to
track down.
> That being said, you can vendor all crates under debian/missing-sources and
> then build from there (see librsvg). ftp-masters *should* accept it even if
> it's vendored as long as you detail everything in d/copyright.
> Security-wise you are responsiblee though, and the release team might not be
> happy about this. Hope this helps.
Ok, that sounds like some useful background - on IRC just now there was
question about how much scrutiny this would get from the ftpmasters.
I hope this doesn't open up too big of a can of worms for you guys, from
what I've gathered there've been some past debates and I don't want to
reopen too much. But this is also a case of "once-burned, twice-shy" for
me, so... tricky stuff :)
Reply to: