Project:Rust

Rust Project
Description	The Rust Project maintains the Rust toolchain and its related packages.
Project email	rust@gentoo.org
Packages	p.g.o/rust@gentoo.org
IRC channel	#gentoo-rust (webchat)
Lead(s)	Georgy Yakovlev (gyakovlev) Self-appointed lead No lead election date set
Member(s)	Arthur Zamarin (arthurzam) Not sure how I got here Matt Jolly (Kangie) Accidentally started maintaining eclasses Michał Górny (mgorny) Forced to maintain one Rust package too many Sam James (sam) Reluctant member
Subproject(s) (and inherited member(s))	(none)
Parent Project	Gentoo
Project listing

The goal of this project is to provide proper packaging of Rust and Cargo for use within the Gentoo ecosystem. The project also maintains cargo.eclass and rust.eclass for use in ebuilds.

app-portage/pycargoebuild is the recommended tool for writing ebuilds for Rust software.

Bumping Rust and Cargo

Network-less builds

It is important to ensure that users of network-less builds or network sandboxing are able to build Rust and Cargo so you should test your ebuilds with the following:

FILE /etc/portage/make.confAdding network-sandbox to FEATURES in Portage

FEATURES="network-sandbox"

Ensure the binary is up to date

When bumping dev-lang/rust, please ensure that dev-lang/rust-bin is kept at the same release. This avoids issues with people mixing versions that Portage can't reason around (note: add the bug #).

Cargo based projects

This includes Cargo itself (and soon Rust itself).

Always use app-portage/pycargoebuild (github) to gather the proper dependencies that need to appear in your ebuild. More than likely, it will will generate a proper ebuild for you. If the package in question contains a Cargo.lock file, the dependencies that the tool creates should not be changed because offline installs will be broken (the cargo.eclass function cargo_update_crates is available to assist with replacing outdated or vulnerable crates).

For projects with a large number of crates (currently >=300, will go down), using the '--crate-tarball' option is recommended. Upload the crate tarball to your devspace and fetch it via SRC_URI. For convenience, it may be a good idea to gate it for 'pkgdiff-mg' using 'PKGBUMPING' variable, e.g.:

CODE Gating crate tarball

CRATE_PV=${PV}
# ...
SRC_URI="
	https://github.com/astral-sh/uv/archive/${PV}.tar.gz
		-> ${P}.gh.tar.gz
	${CARGO_CRATE_URIS}
"
if [[ ${PKGBUMPING} != ${PVR} ]]; then
	SRC_URI+="
		https://dev.gentoo.org/~yourname/dist/uv-${CRATE_PV}-crates.tar.xz
	"
fi

Note that including CARGO_CRATE_URIS is still necessary if there are any GIT_CRATES. A helper CRATE_PV variable is useful to avoid generating a new crate tarball if Cargo.lock did not change.

`rust-dev` overlay

The rust-dev overlay is a prototype experiment for building crates as individual crate units.

This overlay handles each crate similarly to how non-binary programming languages like Perl, Python and Ruby work, by installing (possibly augmented) copies of the extracted crate archives, constructing a local directory registry source as described in source replacement in the cargo book, while deferring actual binary compilation to the relevant target leaves, leveraging slot-operator deps for automatic rebuilds.

But it's currently a very complicated mountain of work and not quite ready for prime-time.

main repo: https://github.com/kentnl-gentoo-rust/rust-dev-overlay
kentnl's work-in-progress: https://github.com/kentfredric/rust-dev-overlay

More details