Hello! I am a Debian Developer, though not likely to work on this as I haven't done a ton of rust binary packaging.

I did want to clear up one misconception that you might be having, though. The .deb versions shipped by upstream are great, but they're not really ever going to be useful for Debian. One of the side-effects of Debian's requirements around software freedom is an important principle: you should be able to build any package in Debian with only the things that are in Debian.

The problem with fresh isn't fresh itself -- packaging that isn't particularly difficult, though it does need some amount of care and attention. The problem is that fresh pulls in 732 different crates which all need to be packaged in Debian before fresh can be. Some of them are already in Debian, of course, but... you can imagine that the effort here is very much not insignificant.

Upstream doesn't have to deal with this problem, as they can simply statically build them into the executables. That's a violation of Debian policy, though, and isn't allowed for anything in the archive.

Hope that helps you understand why you may not get many bites at this offer, generous as it is!

▲

_sinelaw_ 2 days ago | parent | next [-]

(Fresh maintainer here)

Fresh itself has a few dozen direct dependencies. About 33 of those already exist on Debian. It boils down to these missing dependencies:

- The entire oxc toolchain — oxc_allocator, oxc_ast, oxc_codegen, oxc_diagnostics, oxc_isolated_declarations, oxc_parser, oxc_semantic, oxc_span, oxc_transformer

- rquickjs, rquickjs-serde (the QuickJS plugin engine)

- ts-rs

- jsonc-parser

- rust-i18n (this one has an open ITP)

If we build Fresh without plugins enabled, it's just the last three.

▲

MeltedVoltage 4 days ago | parent | prev | next [-]

The problem that Debian has with rust packages is that they try to apply handling a C-style dependency chain (usually only a few C libraries with large scope) for the rust crate ecosystem (a lot of dependencies with small scope). Having to maintain 732 just for one release of a new package is not sustainable.

I don't understand why the policy is not: pulling all crate sources and prepackaging into a tar with associated licenses. The source tree then is part of the package which can still be built from source and gets linked statically.

▲

hlieberman 3 days ago | parent [-]

Security is part of it -- dpkg and apt were not built to deal with the problem of tracking each individual executables' complied library versions. When the next Heartbleed happens, how will you know which things need to be recompiled? (Some of this data exists in adjacent Debian systems for DD's internal use, but it's not integrated into dpkg in any way.)

https://wiki.debian.org/StaticLinking#downsides has some of the background there.

	▲	the__alchemist 3 days ago \| parent [-]
		I think this is a fine description, and respect your reasoning! I think there is in this case, no conflict: Keep the OS-managed packages strict about dependency security, and let the user run the .deb or compiled program Fresh (or whatever software) has provided. So, I think your (Debian perspective), and Fresh (Providing binaries for download, including as a multi-linux script) is on the simpler/easier/just-works end of installing software. No conflicts. Single-CLI line install either way.

▲

jph 4 days ago | parent | prev [-]

Excellent info thank you. Your explanation makes perfect sense, and leads to the security compliance info that I'm reading.

I'm seeking to stop supply chain attacks as described at https://wiki.debian.org/Rust

Could there potentially be a way for a program to include all the source code of all its dependencies, at least for any that aren't on Debian?