kornelski
Workspace-level metadata
Some projects don't have a definite "main" crate in workspace, so it would be nice to be able to define all metadata at the workspace level, esp since workspace-level package metadata is a thing.
How hard would it be for cargo-deb to just read [workspace.package.metadata.deb] or something like this from the top-level Cargo.toml? Maybe keep the name key arbitrary and add a package = "workspace-member" key.
My project is running into this because our "main" will be in src/main/Cargo.toml as our server is completely modular. So there's no [package] key, only a [workspace.package] key at the top level Cargo.toml.
The rationale for this is to make it harder for this kind of metadata or information to go out of sync or outdated, keeping it in the top level is strongly preferred instead of putting it in another Cargo.toml that could get lost.
Additionally, being forced to put this in a workspace now causes assets to use fragile and unappealing relative paths:
license-file = ["../../LICENSE", "3"]
# ..
maintainer-scripts = "../../debian/"
# ..
assets = [
["../../debian/README.md", "usr/share/doc/conduwuit/README.Debian", "644"],
["../../README.md", "usr/share/doc/conduwuit/", "644"],
["../../target/release/conduwuit", "usr/sbin/conduwuit", "755"],
["../../conduwuit-example.toml", "etc/conduwuit/conduwuit.toml", "640"],
]
If my quick design there was implemented, my top level Cargo.toml would look something like this:
[workspace]
resolver = "2"
members = ["src/*"]
default-members = ["src/*"]
[workspace.package]
description = "a very cool fork of Conduit, a Matrix homeserver written in Rust"
license = "Apache-2.0"
authors = [
"strawberry <[email protected]>",
"timokoesters <[email protected]>",
]
version = "0.4.0"
edition = "2021"
# See also `rust-toolchain.toml`
rust-version = "1.77.0"
homepage = "https://conduwuit.puppyirl.gay/"
repository = "https://github.com/girlbossceo/conduwuit"
readme = "README.md"
[workspace.package.metadata.deb]
name = "conduwuit"
# workspace member package name at: src/main/Cargo.toml
package = "conduwuit"
maintainer = "strawberry <[email protected]>"
copyright = "2024, strawberry <[email protected]>"
license-file = ["LICENSE", "3"]
depends = "$auto, ca-certificates"
extended-description = """\
a cool hard fork of Conduit, a Matrix homeserver written in Rust"""
section = "net"
priority = "optional"
conf-files = ["/etc/conduwuit/conduwuit.toml"]
maintainer-scripts = "debian/"
systemd-units = { unit-name = "conduwuit", start = false }
assets = [
["debian/README.md", "usr/share/doc/conduwuit/README.Debian", "644"],
["README.md", "usr/share/doc/conduwuit/", "644"],
["target/release/conduwuit", "usr/sbin/conduwuit", "755"],
["conduwuit-example.toml", "etc/conduwuit/conduwuit.toml", "640"],
]
With this, I no longer need to rely on relative paths from a workspace member in another directory, I no longer need to do -p <package> in my CI for cargo-deb as it can simply read the top level Cargo.toml, and this information is easier to maintain.
At a minimum, would be great if cargo-deb supported relative asset paths from either the workspace root or the crate root, similar to how cargo-generate-rpm works.
cargo-generate-rpm seems to use current directory, and then package-relative path as a fallback. I think that's fragile — the current dir could be anywhere, not just at the root of the workspace, but even completely outside of it. And fallback makes paths ambiguous.
cargo-deb interprets paths relative to CARGO_MANIFEST_DIR. You can use ../../path for assets to reach outside of the crate into the workspace.
