4 ms·
Apart from the fact building it the 'non-C way' results in a magic meat package that you have no idea what it contains: https://hpc.guix.info/blog/2021/09/whats
by llm_trw 2y ago
Apart from the fact building it the 'non-C way' results in a magic meat package that you have no idea what it contains:
https://hpc.guix.info/blog/2021/09/whats-in-a-package/ https://hpc.guix.info/blog/2021/09/whats-in-a-package/
Guix is also a distro that allows for any number of versions of the same package globally, something that language specific dependancy managers do not.
Distors are there for a reason, and anyone who doesn't understand that reason is just another contributor to the ongoing collapse of the tower of abstractions we've built.
- ahupp 2y agoUsing language-native packaging doesn't imply that you have to use binaries from wherever. In the pytorch example you can still build it as a regular part of the distribution, using the C++ dependencies/toolchain, it just means you don't try to stuff it into a versioning/distribution/install model that doesn't match the languages expectations.
- tcfhgj 2y ago> Distors are there for a reason for me: make an os out of the kernel
- pjmlp 2y agoMaking an userspace to Linux kernel, and sorting out disagreements by creating yet another fork.
- kpcyrd 2y agoThis is outdated information. Debian (and other distros) already had their own SBOM format called buildinfo files that encodes this kind of information. In Debian stable ripgrep on amd64 is currently on version 13.0.0-4+b2. The relevant buildinfo file can be found here: https://buildinfos.debian.net/buildinfo-pool/r/rust-ripgrep/rust-ripgrep_13.0.0-4+b2_amd64.buildinfo https://buildinfos.debian.net/buildinfo-pool/r/rust-ripgrep/... It encodes the entire Rust dependency graph that was used for this binary, with exact versions of each crate.