5 ms·

But you don't need to know that for the reproducibility of your product. That's a problem for the maintainer of that crate, but you know that you're getting the

But you don't need to know that for the reproducibility of your product. That's a problem for the maintainer of that crate, but you know that you're getting the same Rust code every time.

pabs3 4y ago
The website being discussed in this thread is about the reproducibility of the crates (or other packages) themselves.
- TheDong 4y ago
  No, it's not about the reproducibility of crates or language-package-manager-packages, it's only about the reproducibility of packages in specific linux distributions. Those linux distributions often include their own custom build scripts and patches to make things reproducible. Debian isn't just execing "npm install" or "cargo install" when you "apt install <package>", so "reproducibility" in the context of this webpage doesn't necessarily mean anything at all about specific crates/packages, other than that the debian/arch/opensuse maintainers were able to make their build process for that package, possibly with patches, reproducible.
  - pabs3 4y ago
    Right now there are indeed zero people working on the reproducibility of crates and other language-package-manager packages, but there is no reason why the site would be restricted to distro packages once the language-package-manager communities start working on the reproducibility of their packages. Some distros actually do run `cargo install` or similar during build, although Debian does not indeed.
- Liquid_Fire 4y ago
  It doesn't make a difference, even if you look at that particular crate itself. Every time you build version X of that crate, you will build the same Rust code. Cargo actually gets this part right. (Of course it doesn't mean building the same Rust code gives you the same binary every time - that's a separate problem) Sure, _updating_ the crate might be a nightmare if the generation part is not stable - but that's unrelated to reproducibility.
bheadmaster 4y ago
> you know that you're getting the same Rust code every time Since code is generated, that could be considered the same as saying "you know you're getting the same binary every time" for pre-compiled binaries. The key argument is whether "generated code" can be considered "source code" or not. Personally, I'd say no - "source code" almost always refers to the preferred representation that humans are editing. If code is generated, then the true source code is the code of the generator and its input. A similar distinction is declared in the GNU General Public License, to prevent companies from circumventing the spirit of the license by releasing obfuscated source code. Rule of thumb: If the original author is not editing it directly, it's not source code.
- Liquid_Fire 4y ago
  Whether this distinction matters entirely depends on what your end goal is for which you want reproducible builds. Besides, it's not a problem that Cargo alone can solve. At the end of the day it's picking up code from a git repo, and how you produced the code in that repo is not something it could control.

But you don't need to know that for the reproducibility of your product. That's a problem for the maintainer of that crate, but you know that you're getting the same Rust code every time.

pabs3 4y ago

The website being discussed in this thread is about the reproducibility of the crates (or other packages) themselves.

TheDong 4y ago
No, it's not about the reproducibility of crates or language-package-manager-packages, it's only about the reproducibility of packages in specific linux distributions. Those linux distributions often include their own custom build scripts and patches to make things reproducible. Debian isn't just execing "npm install" or "cargo install" when you "apt install <package>", so "reproducibility" in the context of this webpage doesn't necessarily mean anything at all about specific crates/packages, other than that the debian/arch/opensuse maintainers were able to make their build process for that package, possibly with patches, reproducible.
- pabs3 4y ago
  Right now there are indeed zero people working on the reproducibility of crates and other language-package-manager packages, but there is no reason why the site would be restricted to distro packages once the language-package-manager communities start working on the reproducibility of their packages. Some distros actually do run `cargo install` or similar during build, although Debian does not indeed.
Liquid_Fire 4y ago
It doesn't make a difference, even if you look at that particular crate itself. Every time you build version X of that crate, you will build the same Rust code. Cargo actually gets this part right. (Of course it doesn't mean building the same Rust code gives you the same binary every time - that's a separate problem) Sure, _updating_ the crate might be a nightmare if the generation part is not stable - but that's unrelated to reproducibility.

bheadmaster 4y ago

> you know that you're getting the same Rust code every time Since code is generated, that could be considered the same as saying "you know you're getting the same binary every time" for pre-compiled binaries. The key argument is whether "generated code" can be considered "source code" or not. Personally, I'd say no - "source code" almost always refers to the preferred representation that humans are editing. If code is generated, then the true source code is the code of the generator and its input. A similar distinction is declared in the GNU General Public License, to prevent companies from circumventing the spirit of the license by releasing obfuscated source code. Rule of thumb: If the original author is not editing it directly, it's not source code.

Liquid_Fire 4y ago
Whether this distinction matters entirely depends on what your end goal is for which you want reproducible builds. Besides, it's not a problem that Cargo alone can solve. At the end of the day it's picking up code from a git repo, and how you produced the code in that repo is not something it could control.