[ reply to d-devel only, as more suitable for Debian-wide issue ] Quoting Ian Jackson (2022-12-15 11:41:13) > I would like to add the following entry to the table of build > profiles in BuildProfileSpec: > > Profile anme: `cargo-upstream` > Can cause changes to built binaries, including functional chnges. (Y) > Should not cause changes to set of build debs. (N) > Description: > Obtain Rust dependencies from crates.io, not from Debian; use a > `Cargo.lock` from the source package if there is one. Will usually > cause cargo to make network accesses. Ideally, behaviour of the > resulting programs will be the same, but this is not guaranteed. > > This is useful when developing packages which are to be uploaded to > Debian, but whose build dependencies are not yet available in the > targeted suite.
Similar pain for other upstream ecosystems as well - I know about npm for NodeJS modules, but imagine it is similar for Java and others as well. What is the benefit of introducing a standardized flag for this relatively narrow scope, compared to doing non-standardized fetching of crates _before_ package build and building with those embedded? Example of doing that is here: https://salsa.debian.org/debian/helvum (essentially doing `cargo vendor --versioned-dirs debian/vendorlibs`). If there is really a need for a standardized flag, then what is the benefit of a narrow one specific to cargo, compared to a more general "fetches-source-during-build" that would be suitable also for e.g. NodeJS fetching npm modules? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
