Hi all--

If i try building rust-sequoia-openpgp (e.g. using debuild -uc -us) as a
non-privileged user on a system that has some unnecessary dependencies
installed, i will sometimes get a failure during build.rs that looks
something like the following (this example is from building on a system
that has the previous version of librust-sequoia-openpgp-dev installed):
-----
     Running `/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/target/debug/build/sequoia-openpgp-0b6c8220513fd567/build-script-build`
[sequoia-openpgp 1.20.0] Selected cryptographic backend: Nettle
[sequoia-openpgp 1.20.0] processing file `/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/debian/cargo_registry/sequoia-openpgp-1.19.0/src/cert/parser/low_level/grammar.lalrpop`
[sequoia-openpgp 1.20.0] thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', build.rs:10:29
[sequoia-openpgp 1.20.0] stack backtrace:
[sequoia-openpgp 1.20.0]    0: rust_begin_unwind
[sequoia-openpgp 1.20.0]              at /usr/src/rustc-1.70.0/library/std/src/panicking.rs:578:5
[sequoia-openpgp 1.20.0]    1: core::panicking::panic_fmt
[sequoia-openpgp 1.20.0]              at /usr/src/rustc-1.70.0/library/core/src/panicking.rs:67:14
[sequoia-openpgp 1.20.0]    2: core::result::unwrap_failed
[sequoia-openpgp 1.20.0]              at /usr/src/rustc-1.70.0/library/core/src/result.rs:1687:5
[sequoia-openpgp 1.20.0]    3: core::result::Result<T,E>::unwrap
[sequoia-openpgp 1.20.0]              at /usr/src/rustc-1.70.0/library/core/src/result.rs:1089:23
[sequoia-openpgp 1.20.0]    4: build_script_build::main
[sequoia-openpgp 1.20.0]              at ./build.rs:10:5
[sequoia-openpgp 1.20.0]    5: core::ops::function::FnOnce::call_once
[sequoia-openpgp 1.20.0]              at /usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
[sequoia-openpgp 1.20.0] note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: failed to run custom build command for `sequoia-openpgp v1.20.0 (/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0)`

Caused by:
  process didn't exit successfully: `/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/target/debug/build/sequoia-openpgp-0b6c8220513fd567/build-script-build` (exit status: 101)
  --- stdout
  processing file `/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/debian/cargo_registry/sequoia-openpgp-1.19.0/src/cert/parser/low_level/grammar.lalrpop`

Over on #debian-rust, we did a bit of archaeology to determine why
1069212 is happening.

It looks like tools that use lalrpop by default will descend into the
current working directory and act on any *.lalrpop there.

The reason that they stumble upon unwritable files is that "cargo
prepare-debian" is being invoked with --link-from-system, instead of
just pointing to /usr/share/cargo/registry directly.

cargo prepare-debian is getting --link-from-system by default due to
choices in dh-cargo.

The revision history of *why* this is on by default is unclear, sadly.

We were able to identify two cases where --link-from-system might be
necessary:

0) a case where a crate has no dependencies at all.  in that case, on
   the buildd, it's possible that /usr/share/cargo/registry doesn't
   exist at all (no librust-*-dev packages installed) and so
   --link-from-system avoids pointing to a non-existant repo (instead it
   points to an empty repo).

1) a case where some crate wants to "vendor" a third-party crate that
   isn't packaged for debian directly.

case (1) seems likely to be pretty unusual.  Case (0) also seems unusual
(how many dependency-free packages are there?) but also seems like kind
of a distinct bug.  if there are no crate dependencies, then there's no
need to ask cargo to look at a repository of crates anyway.

So it seems simpler and more robust to avoid using --link-from-system by
default, and let the crates that really need to use it override it
directly.

If there's a marginally common case for using --link-from-system, maybe
debcargo should grow an configuration choice that those crates that do
need it can just set directly.