Re: [PATCH 1/2] cargo.eclass: for EAPI 9, ban cargo_src_install

On Fri, 29 May 2026 at 16:24, Eli Schwartz <[email protected]> wrote:
> On 5/29/26 6:33 AM, Michał Górny wrote:
> > On Thu, 2026-05-28 at 17:56 -0400, Eli Schwartz wrote:
> >> cargo pretends to be a package manager
> >> and a build system, but is neither -- only a compiler-wrapper.

I agree Cargo is barely a package manager, but it certainly is a build
system that does more than just wrap the compiler. Is there a specific
thing you're missing ?

> >> "cargo install" recompiles the binary so it is not what you tested in
> >> src_test.

That is expected and desired: tests are normally compiled with full debug,
and you don't want the test symbols in your release build. Some other
build systems support that too.

> >> It does so during the src_install phase, and it (mostly?)
> >> doesn't respect incremental builds or caching intermediate outputs.

It's doing a decent job (and slowly improving) considering the language's
design. But in the context of an ebuild, we don't care ?

> >> It
> >> also cannot install anything other than what doexe does, since cargo
> >> doesn't support *building* multiple output types, let alone installing
> >> them in a uniform way.

Yes, in the end it just copies the executables somewhere, with little
flexibility.
But it only cares about Rust code, it's not going to build or install man pages
for example.

> >> Simply require users to use doexe like for any other package without a
> >> standard (autotools, meson, cmake etc.) build system.

Doexe would work, but cargo_src_install adds a bit of convenience: ebuild
authors don't have to check the executable names or where they are generated.
It's normally in target/release/$PN but some packages can get fancy, and
https://rust-lang.github.io/rust-project-goals/2025h2/cargo-build-dir-layout.html
could potentially complicate things.

I'm still not clear on why we want to deprecate cargo_src_insall. Is it buggy,
or a maintenance burden ?

> There isn't much to gain, and on the flip side I don't really understand
> what the underlying difference between cargo build and cargo install is.
> Clearly they are different somehow, and my assumption is that something,
> somewhere, is not properly respected by cargo install.

The differences are fairly small:
* Default to release profile instead of dev (we surely already set that)
* Default to use latest compatible deps (we already deny that)
* Actually copies the executable (convenient, as stated above)
* Maintains installation metadata (a hindrance for us, but we handle it)
* Allows installing from web instead of local repo (we don't care about that)

-- 
Vincent de Phily