Correct, the goal of my work is that on an official pristine Debian system you can type (your commands above, or)
apt install safe-network-node safe-network-cli and get
sn_cli installed - integrated with the system, and security-tracked and upgraded as integral part of that.
Yes: All code distributed as part of Debian must be built from source in a pristine Debian environment, and must be possible to rebuild using only the distributed system.
Yes (in one interpretation of your question): All crates must be included in source form as part of Debian, and built from source to produce all binary packages part of Debian.
Needed code (crates and C libraries and build tools) need to be included with Debian, but need not be duplicated in each source package. In fact it is strongly discouraged to duplicate code in Debian, which is the main reason the current draft package is not released into Debian yet: I want to reduce the amount of embedded crates, ideally to zero, before formally pushing it to Debian.
Also, Salsa is not officially part of Debian, but is just a common (by far!) place to prepare packages to be pushed to Debian. Debian predates the invention of git, and a “Debian source package” really is a couple of tarballs (one with upstream code and one with packaging code) and a cryptographically signed metadata file.
But loosely speaking, yes: All crates in the graph must be packaged for Debian!
Yes: When a Debian package is built only other binary Debian packages can be pulled in as build-dependencies.
So each and every build-dependency need to exist as a Debian binary package (or cheating and embedding, as I do now for the draft package).
I normally maintain packages with a "slightly slower release frequency
[Not sure if you are asking how well I usually keep up, or how I techincally do, or…]
For each package update (ideally each upstream release, but can skip some or many upstream releases, there is no strict rule), I download the upstream release tarball (or when that is not available - as is the case for crates - I synthesize a tarball from upstream git release tag), and update my packaging tarball to align with that newer upstream code.
I maintain (alone or as part of teams) roughly 600 packages in Debian. By far the most of them have much fewer dependencies than to this one, though.
Here I meant invitations for regular not-so-geeky users to help out.
…but I guess your interest is more how strong testing we can expect.
Currently there is very sloppy testing: I simply execute
cargo test, skipping some tests I experienced failing (likely because they rely on network but maybe I miss some environment setup) and ignore the result.
Obviously I hope that can change to check all tests and to fail the build if any of the tests fail.
Besides the build-time testing I also expect to add runtime tests, when package is officially in Debian and I can rely on Debian infrastructure for that.
Perhaps it is helpful to you to see how a Debian developer “dashboard” looks like - here is one for another (very simple) Rust package: precious - Debian Package Tracker
And here is one for a non-Rust package with test failures, that has caused the package to be kicked out of the “testing” branch of Debian: eye - Debian Package Tracker
Certainly: The version listed in initial post of the “ITP” (intent to package) bugreport reflects where work initially began, more than 4 months ago. To check which version the packaging is currently aligned with, see topmost section of the package changelog.
Feel free to ask more questions. We can also meet for an audio chat if you like - I host a lightweight videoroom service myself at https://live.jones.dk/ that I prefer to use for that purpose. Just say a time that is suitable for you - I am generally online and flexible with time (rarely in fixed-time meetings).