How should workspaces be handled?

[kornelski]

Currently, cargo-deb always assumes its target crate is a single binary crate that makes a single debian package. It doesn't do anything special for Cargo workspaces. Should it?

How should a Cargo workspace translate to a Debian package? If you run cargo deb in the root of a workspace:

• Should it be an error?
• Should it merge all sub crates into one deb package?
• Should it create a separate deb package for each crate in the workspace? Should there also be a root package that depends on all the sub packages?
• ???

Would you expect cargo-deb to handle shared libraries? Do you make debs for dynamic libraries (cdylib type) and binaries that depend on them?

[RReverser]

Just as a data point, in our project I'm just calling cargo deb in particular crate I need to package (it just exposes FFI bindings to the other crate in a workspace) and in that configuration I don't see a need for special workspace support, apart from maybe a better error message (currently it complains about lack of name property in Cargo.toml).

[fredszaq]

Adding another datapoint :
We currently have a big workspace with 30+ crates, some of which are destined to but packaged as debs, some being package in other ways, and some being dependencies the previous two types.
At the moment when we need to package a crate into a deb, we cd into that crate dir and run cargo-deb from here. That work reasonably well. Here's what we find is missing :

• a -p flag to change the project to build when launching cargo-deb from the root of the workspace
• the root path used to resolve assets should be the project dir and not the workspace dir (see Assets path are resolved relative to workspace dir instead of Cargo.toml dir #58 )

We don't have at the moment the need to create a deb containing all the crates of a workspace.

[acfoltzer]

I also have been successfully using cargo deb in workspaces. The main issue I have is the fact that it calls cargo build --release --all, so I have to wait for the whole workspace to build even when I just want one package. Passing the package through to Cargo doesn't work (e.g., cargo deb -- -p mycrate), presumably because the --all overrides it.

[notriddle]

Currently, my workspace has three crates in it.

• One crate is a core library. I don't want to try to build a deb for it.
• One crate is a CLI tool and a daemon. I am building a deb based on it. It also uses cargo-rpm.
• One crate is a windows GUI and Service* that depends on the CLI and the core library. I don't even want to compile that. It's using cargo-wix.

* basically just a wrapper around the daemon that speaks the service management protocol and logs stdout to the event viewer

[cstrainge]

I have a project that could really use this.

I have multiple binaries that are all inter-related, and library crates built as .so files that they share between them. I would love to be able to easily construct a single .deb that packages this all up properly.

[kornelski]

I've added -p option that takes a package name (cargo allows "SPEC" but it's too complicated to replicate the full syntax). It will make a deb for the given package in the workspace.

I probably won't be adding support for making one deb from multiple packages in one go, since the deb needs package metadata, and combining metadata from multiple packages complicates things too much.

[pguedes]

I probably won't be adding support for making one deb from multiple packages in one go, since the deb needs package metadata, and combining metadata from multiple packages complicates things too much.

any suggested workaround to build one deb from multiple crates?

[wpbrown]

any suggested workaround to build one deb from multiple crates?

This seems to be a viable workaround:

Pick an arbitrary package like foocli to be the deb package. Add to foocli Cargo.toml:

[package.metadata.deb]
name = "foo"
assets = [
    ["../target/release/fooservice", "usr/lib/foo/fooservice", "755"],
    ["../target/release/foocli", "usr/sbin/foocli", "755"],
]

Then for creating the deb:

cargo build --release
cargo deb --manifest-path foocli/Cargo.toml --no-build

I probably won't be adding support for making one deb from multiple packages in one go

@kornelski Along the lines of this workaround, without having to answer all the complexities in the OP, could you just require assets definition if the Cargo.toml is a workspace. Don't attempt any merging of metadata from the packages. Just build the workspace, get all metadata from the workspace Cargo.toml package section, and leave it up to the user to decide how to assemble the assets.

This would improve above in that I could just run plain cargo deb and I wouldn't need the .. in my asset paths.

[kornelski]

Currently cargo-deb builds with --all flag (which maybe it shouldn't always do: #125), which builds the whole workspace, so you can grab binaries from other crates in the same workspace. So if you start the build from the root of the workspace, and specify a package with -p or put one in the root Cargo.toml, it should work.

[wpbrown]

Thanks @kornelski . The -p option is a nice improvement. I like that it builds the workspace. I can simplify my process to just:

cargo deb -p foocli

However, choosing foocli package to host the deb meta data is still arbitrary.

I've tried putting a package and package.metadata.deb section in the workspace Cargo.toml, but then I get

cargo-deb: cargo (metadata): error: failed to parse manifest at `/home/dev/system/Cargo.toml`

Caused by:
  no targets specified in the manifest
  either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present

Without this verification, it may work as expected with the assets definition replacing the need for target information.

[eddycurrently]

For a project I work on, we are currently using cargo deb in a workspace, and for the way we use it it would be useful if we could set some package fields at the workspace level. The main ones would be version and revision. Maintainer might also be useful too. I would imagine that this could just be added in the workspace level Cargo.toml, and any fields set in a sub-project would override the workspace value.

[kornelski]

There is an RFC for sharing metadata at the workspace level: rust-lang/rfcs#2906

[eddycurrently]

@kornelski, thanks, I was not aware of that, the RFC looks hopeful. I would assume any progress on cargo deb in this respect would be waiting on that?

[kornelski]

I mean that's the direction cargo is taking. Any solution for cargo-deb should probably mimic that.