It would be great to save a reasonable amount of bandwith when fetching the stages, and as upstream hosts them anyway, it should be no problem to change the src_uri of all of those three to .tar.xz As fare as I'm concerned, untar performance is higher for low end devices with xz compression. Which would be the only case I can imagine this to be usefull.
It would be nice to have it for the source as well, but it is mainly the stage0's which are wasting the bandwith, where it goes from 70mb with xz and 180mb with gz compression.
dev-util/cargo-0.27.0, dev-lang/rust-1.26.0 and dev-lang/rust-bin-1.26.0 use the xz-compressed tarballs where available.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=71eba02631d5129e1e4c2729f4234727d7bac498 commit 71eba02631d5129e1e4c2729f4234727d7bac498 Author: Dirkjan Ochtman <djc@gentoo.org> AuthorDate: 2018-05-14 13:37:00 +0000 Commit: Dirkjan Ochtman <djc@gentoo.org> CommitDate: 2018-05-14 14:38:35 +0000 dev-lang/rust: version bump to 1.26.0 Use LLVM_TARGETS to decide which targets to build for bundled LLVM. Use xz-compressed tarballs where possible to limit bandwidth/storage. Fixes: https://bugs.gentoo.org/627288 Fixes: https://bugs.gentoo.org/655600 Package-Manager: Portage-2.3.24, Repoman-2.3.6 dev-lang/rust/Manifest | 4 + dev-lang/rust/rust-1.26.0.ebuild | 181 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 185 insertions(+)
reopening because tar.gz is back with =dev-lang/rust-1.29.2 reason is that the new eclass defaults to tar.gz while constructing the download url.
Fixed again.
reopening because tar.gz is back with =dev-lang/rust-bin-1.29.2 reason: more coffee? :-)
Yesterday portage wanted to download the tar.gz for rust-bin-1.29.2, today it's going to use tar.xz, no idea why this happened.
