Re: Rust policy for bcachefs-tools in Debian
On Sun, Sep 14, 2025, at 8:08 PM, Kent Overstreet wrote:
> On Sun, Sep 14, 2025 at 07:33:56PM +0200, Matthias Geiger wrote:
>> - 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).
Yeah, that's not how security updates are done in Debian (except sometimes
in unstable ;)). For stable, you absolutely need a minimal fix targeting
just the issue at hand, unless you have a proven track record and agreement
with the security team which allows you to import collected security fix
*releases* done upstream, or something like that. Wholesale updating of
dependencies is only done as a last resort (see below).
> [..]
>
>> - 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.
It is, because we don't want to have 25 slightly different copies of the same
code in the archive. We want to ideally have a single copy (per release), so
that we only have to analyze and fix that one (and potentially rebuild things
statically linking it).
This is a fundamental clash between how distros like Debian, and some upstream
ecosystems (like Rust/crates.io, but also npm, ..) operate.
>> - 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 :)
I'd advise giving them a heads-up before you spend significant time on such
packaging efforts, unless you want to build and publish such a package on your
own anyway in case it gets rejected. Basically outline your reasoning (I'd
keep it a bit shorter than in this thread though) and give some numbers about
the scale of vendoring (e.g., number of crates/LOC/files/bytes). Please be
patient, it might take a while for them to get back (e.g., if they want to
have an internal discussion and decide based on that).
Fabian
Reply to: