You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I modified the Debian cargo buildsystem to use auditable (finally) But ran into an issue that is maybe a bit philosophical in how it should be solved.
This is the error message from a test run trying to compile lsd:
thread 'main' panicked at 'cargo metadata failure: error: no matching package named `assert_cmd` found
location searched: registry `crates-io`
required by package `lsd v0.23.1 (/<<PKGBUILDDIR>>)`
', src/collect_audit_data.rs:77:9
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: could not compile `lsd`
assert_cmd is a dev-dependencies to lsd, and the Debian build system doesn't inject those in the environment when running the cargo install command.
That is hard to change, as that would introduce a large number of dependency loops.
Is it important to collect dev-dependencies, or could cargo metadata be instructed to not look for those maybe (This I haven't researched yet)?
The text was updated successfully, but these errors were encountered:
I am not aware of any such mechanism. Perhaps there is some nightly config flag to keep going on failures? It's worth taking a look at, but I doubt there is one.
Since this is an issue in cargo metadata and not cargo auditable itself, unfortunately it is not something I can directly fix.
I modified the Debian cargo buildsystem to use auditable (finally) But ran into an issue that is maybe a bit philosophical in how it should be solved.
This is the error message from a test run trying to compile lsd:
assert_cmd
is a dev-dependencies to lsd, and the Debian build system doesn't inject those in the environment when running thecargo install
command.That is hard to change, as that would introduce a large number of dependency loops.
Is it important to collect dev-dependencies, or could cargo metadata be instructed to not look for those maybe (This I haven't researched yet)?
The text was updated successfully, but these errors were encountered: