I want to use Fresh Editor (https://getfresh.dev/). This is because Fresh is easier to learn quickly than vim & emacs, and more of an IDE than micro & nano, and more favorable for compliance auditing because of its core-and-plugins architecture and open source code using Rust.
I would like to donate toward this goal. I can afford to offer $100 to any Debian Developer who has the suitable skill and trust to accomplish this. The software author must say yes too, of course.
Success looks like this: create a new Debian 13 server, type "apt install fresh-editor", and it works. No third-party apt sources needed, because I have compliance reasons. Fortunately Fresh already has a *.deb file and explains it on the Fresh installation page.
Here's the GitHub issue: https://github.com/sinelaw/fresh/issues/2169
I'm not affiliated with Fresh in any way, just a early adopter user. If you view the GitHub issues, I'm also offering $100 each for helping with Fresh display issues on MacBooks, and for adding Fresh ePub capabilities.
I'm doing this because I believe in funding open source as much as possible.
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!
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.
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.
https://wiki.debian.org/StaticLinking#downsides has some of the background there.
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?
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.
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)
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)
I recognize that a lot of Linux users like the package system. I think it's a great tool for software that's intended to be integrated with the OS, but is a bit of a mismatch for third-party software. The creators here have even build a .deb, which is above and beyond. (Compared to, for exmple, compiling a +x linux executable that has been tested on Debian)
So, from a writer and user of software, I think I would rather publish the executables or a script to install them on my website (as they have done) for all the major OS branches, and as a user, I think c+ping and launching the CLI command they provided front and center is fantastic. It's an above-avg experience; a trivial install process, which isn't a given for OSS.