Item — HN Reader

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)

1 comments

That is some attention to detail in your research! I appreciate the explanation and examples. I think perhaps I am deliberately dodging the OP's question, treating it as an X/Y problem. He or she mentioned compliance as a valid reason, but it still feels like a smell: I think the original software could be installed using the provided deb, or building from source by cloning the repo and running `cargo run` on a Debian or Ubuntu system older than or the same version as the one he intends to use. (A Rule of Thumb I've found works well for Debian!)

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.