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!
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.
Debian Trixie has already been released. The packages going into Trixie were frozen on April 25, 2025. If you want a new package in the official Debian repos, it needs to be packaged for Unstable, then promoted to Testing, then eventually Testing will be cut as a Stable release. The next Testing freeze will probably be sometime next year.
This feels like a good example of open source economics.A relatively small amount of money can create value for everyone who used Debian in the future.
IMO this isn't part of your OS; it's cross-platform PC software. Install it using the bin its creators have provided. They have even built and are hosting a Deb for your linux distro (From inspection of the script)
I see in your posts that you do a lot with Rust and biology. Broadly, the same way you can use the tool "cargo install" to fetch a bunch of dependency crates from one source and be sure their versions can all run well together and update together, I can use the tool "apt install" to do the same for applications.
The concept is called a "package manager" and it greatly helps me achieve a concept called "reproducible builds", as I gradually migrate the work toward a package manager for reproducible builds called "Nix".
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!
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.
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?
This isn't going to happen.
Debian Trixie has already been released. The packages going into Trixie were frozen on April 25, 2025. If you want a new package in the official Debian repos, it needs to be packaged for Unstable, then promoted to Testing, then eventually Testing will be cut as a Stable release. The next Testing freeze will probably be sometime next year.
Good info, thank you. I'll aim for the next version with $100 to get it into Debian 14. <3
This feels like a good example of open source economics.A relatively small amount of money can create value for everyone who used Debian in the future.
Out of the loop: Why not run this, from the top of the home page: curl https://raw.githubusercontent.com/sinelaw/fresh/refs/heads/m... | sh
IMO this isn't part of your OS; it's cross-platform PC software. Install it using the bin its creators have provided. They have even built and are hosting a Deb for your linux distro (From inspection of the script)
I see in your posts that you do a lot with Rust and biology. Broadly, the same way you can use the tool "cargo install" to fetch a bunch of dependency crates from one source and be sure their versions can all run well together and update together, I can use the tool "apt install" to do the same for applications.
The concept is called a "package manager" and it greatly helps me achieve a concept called "reproducible builds", as I gradually migrate the work toward a package manager for reproducible builds called "Nix".
https://en.wikipedia.org/wiki/Package_manager
https://en.wikipedia.org/wiki/Reproducible_builds
https://en.wikipedia.org/wiki/Nix_(package_manager)
thank you for creating gitalias, very useful!
You're welcome, thanks for the shout out. Glad it's helping you. <3