On Wed, Jul 31, 2019 at 08:00:00PM -0700, Ivan Petkov wrote: > Hi Efraim, > > > On Jul 30, 2019, at 3:46 AM, Efraim Flashner wrote: > > > > This one I'm pretty happy with. The checksums are only generated twice > > when there's a Cargo.lock file present and I've factored out the > > function to generate all the checksums. When that's moved to (guix build > > cargo-utils) it can be used by the rust compilers and icecat. > > Overall the patch makes sense to me! > > However, I am curious what are some of the situations in which you’re encountering > a Cargo.lock file? In a system like guix which maintains all dependencies immutably > and consistently, the Cargo.lock file is virtually useless (in fact it *could* be harmful > if an application is released with a Cargo.lock file pinning to a particular vulnerable > dependency which needs to be updated, requiring patching of the Cargo.lock file). One is the package that I'm actually targeting, https://github.com/chfi/rust-qtlreaper/ , and three of the others are rust-regex and rust-compiler-builtins and rust-env-logger. All three of them I got from $(guix import crate foo). `guix import crate env-logger`, for example, returns this: https://static.crates.io/crates/env_logger/env_logger-0.6.2.crate > > I’d be willing to go as far as suggest we unconditionally delete any Cargo.lock file > in source tarballs and let cargo generate its own replacement using the vendor > directory we have supplied. (Imports from crates.io also never include a Cargo.lock > file, so this may only pertain if we’re performing a direct source import…) This is basically what my 'update-cargo-lock phase does. Otherwise we end up packaging arbitrary versions of crates to satisfy whatever version they were using when they last updated their Cargo.lock. > > —Ivan -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted