Package: cargo
Version: 0.66.0+ds1-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.ca...@sideload.33mail.com

Cargo has proven to be seriously fragile and flimsy when it comes to
fetching large files from the cloud. Cargo is also (inadvertently)
designed to trap users so there is no mechanism by which users can use
more robust tools for the download and then feed the file to
cargo. Installing a package took a few days of running around a city
to try different internet connections and different libraries and
cafes until a single connection was found to be up to the full task.

The procedure was like this:

===8<----------------------------------------
$ env -C /usr/local/src git clone --config http.proxy=http://127.0.0.1:8118 
https://github.com/wireapp/cryptobox-c
$ env -C /usr/local/src/cryptobox-c make
  cargo build
    Updating crates.io index
    warning: spurious network error (2 tries remaining): http parser error: 
stream ended at an unexpected time; class=Http (34)
       Fetch [                         ]   3.11%, 33.10KiB/s                    
                                       warning: spurious network error (1 tries 
remaining): http parser error: stream ended at an unexpected time; class=Http 
(34)
       Fetch [                         ]   2.47%, 44.87KiB/s
===8<----------------------------------------

The “cargo build” was tried probably ~30 or so times. Sometimes over
tor; sometimes over a vpn; often over normal clearnet.

The following was added to /usr/local/src/cryptobox-c/Cargo.toml and
various parameters were fiddled with to try to get more forgiveness on
the network problems:

===8<----------------------------------------
[http]
#proxy = "http://127.0.0.1:8118"; # HTTP proxy in libcurl format
timeout = 80                    # timeout for each HTTP request, in seconds
low-speed-limit = 1             # network timeout threshold (bytes/sec)
multiplexing = false            # HTTP/2 multiplexing

[net]
retry = 30                  # network retries
git-fetch-with-cli = false  # use the `git` executable for git operations
===8<----------------------------------------

That was futile. A warning was given about the section titles “[http]”
and “[net]”, but some of the parameters seemed to take effect.

There was also no way to pass in git parameters. It
would have been useful to pass in

  “--depth 1 --shallow-submodules”

Setting git-fetch-with-cli=true would not help because shallow
fetching options are not offered by git as global configuration
variables.

The verbose logs showed that it made around ~40% progress on a ~750mb
file and die due to spurious network errors. Then on the next attempt
it would only get 10% of that same file, starting from the beginning.

I had to connection shop, travelling around town until I could find a
high-bandwidth low-latency connection at a time of day with relatively
low traffic to get the package downloaded. It finally succeeded but
only because of that overperforming uplink was available to me.

Many improvements are needed:

① a way to pass in git options.

② crash recovery/resume - it’s crazy to fetch half of a 700mb file and
then throw it all away and start over when the network fails.

③ a way to be informed about the exact URL being fetched so we can use
something like “aria2c -c” or “wget -c” to fetch the big files using
robust tools dedicated to this purpose. (maybe http.debug covers
this.. not tested)

④ when cargo quits due to spurious network errors, it needs to keep
the partial download around and tell users where the partial file is.

⑤ a way to feed a complete local file to cargo to use in place of
whatever it would normally fetch. 

⑥ a way to specify a log file. All output was dumped to the terminal
and no transcription mechanism was being used. The man page and the
config manual¹ make no mention of a logfile option.

The files that gave the most grief were apparently standard libraries
not specific to cryptobox. The full Debian release disk (90gb, which I
have on-hand) likely even has the file that was needed somewhere. But
cargo lacked the options needed to put it to use.

This is tagged with severity normal. The five improvements listed
above may technically be “wishlist” severity, but it seems more like a
defect that cargo is essentially rendered dysfunctional on any less
than perfect or average network.

¹ https://doc.rust-lang.org/cargo/reference/config.html

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cargo depends on:
ii  binutils             2.40-2
ii  gcc [c-compiler]     4:12.2.0-3
ii  gcc-10 [c-compiler]  10.2.1-6
ii  gcc-12 [c-compiler]  12.2.0-14
ii  libc6                2.36-9+deb12u6
ii  libcurl3-gnutls      7.88.1-10+deb12u5
ii  libgcc-s1            12.2.0-14
ii  libgit2-1.5          1.5.1+ds-1+deb12u1
ii  libssh2-1            1.10.0-3+b1
ii  libssl3              3.0.11-1~deb12u2
ii  rustc                1.63.0+dfsg1-2
ii  zlib1g               1:1.2.13.dfsg-1

cargo recommends no packages.

Versions of packages cargo suggests:
pn  cargo-doc  <none>
ii  python3    3.11.2-1+b1

-- no debconf information

Reply via email to