systemd example

[GopherJ]

Hello, I would like to use cargo-deb to replace my bash script. I need openssl and someother dev packages as dependencies.

At the same time, I would like to be able to manage my application using systemd (status, stop, start...).

I also have Config.toml which should be put together with the binary.

Could you please give me some information on how to achieve this using cargo-deb? thanks!

[kornelski]

You'd use

depends = "$auto, systemd, openssl, someother-dev"

we have systemd example here:

https://github.com/mmstick/cargo-deb#example-of-custom-cargotoml-additions

[GopherJ]

@kornelski Hello, thanks that basically works, I just get some warning like this:

warning: ldd (/home/cheng/Project/Ubudu/ACS/server/Config.toml):  (no auto deps for /home/cheng/Project/Ubudu/ACS/server/Config.toml)
warning: ldd (/home/cheng/Project/Ubudu/ACS/server/tls/cert.pem):  (no auto deps for /home/cheng/Project/Ubudu/ACS/server/tls/cert.pem)
warning: ldd (/home/cheng/Project/Ubudu/ACS/server/target/x86_64-unknown-linux-musl/debug/acs_server):  (no auto deps for /home/cheng/Project/Ubudu/ACS/server/target/x86_64-unknown-linux-musl/debug/acs_server)

do you know how to remove them?

[GopherJ]

and also I specified already the license-file file both in package meta and deb meta, still got this warning:

warning: license field is missing in Cargo.toml

Any way there is no error and it works perfeclty, hope you can let me know what's the cause for this type of warning. Thank you for the great work!

[ximon18]

The systemd example only seems to be a dependency on systemd, not an example of making your application manageable as a systemd unit. I'm looking at this right now and you seem to need a unit file asset and a postinst maintainer-script (the latter if you want the unit enabled or maybe even started). In the simplest case something like this in Cargo.toml:

assets = [
    ...
    ["debian/assets/your.service", "/etc/systemd/system/your.service", "644"]
    ...
]

(assuming you had a debian/assets subdirectory in your project)

To enable/start the unit post install you'd then also need in Cargo.toml:

maintainer-scripts = "debian/scripts/"

And a debian/scripts/postinst script like:

#!/bin/sh -ex

enable_and_start_service() {
    if ! systemctl is-enabled your.service >/dev/null; then
        systemctl enable --now your.service
    fi
}

case "$1" in
configure)
    enable_and_start_service
    ;;
esac

Unfortunately the unit file content is dependent on which systemd version the target O/S supports, e.g. Ubuntu 16.04 and Ubuntu 18.04 don't support Type=exec as that was introduced in a more recent version of systemd than is bundled with those O/S versions, similar story with Debian releases.

What I haven't worked out is how to use cargo deb to build packages for different O/S target versions, the only way I can currently imagine is to use additional Cargo.toml files which will be a lot of copy/pasting to maintain!

FYI I looked for inspiration at the fpm packaging tool and that introduced systemd support with issue 952, the diff showing which commands they added that would be needed in maintainer scripts can be seen here: https://github.com/jordansissel/fpm/pull/952/files

Hmm, I suppose the assets could include multiple systemd unit files and the postinst maintainer script could only move the right one for the current O/S into the correct place on the filesystem? I'm not sure how that fits with the Debian packaging philosophy.

Updarte: One could also use a single Cargo.toml file by having file assets/A.service and assets/B.service and in Cargo.toml referene the non-existing assets/your.service, and just prior to invoking cargo deb copy either assets/A.service or assets/B.service to assets/your.service. It's still a hack but at least it doesn't involve maintaining two separate Cargo.toml files which are 99% identical.

[ximon18]

So I just came across https://github.com/mmstick/cargo-deb/issues/100 which relates to this. Additionally I just discovered cargo deb --variant described in the --help as "Alternative configuraiton section to use" which would avoid the need for duplicate Cargo.toml files when building DEBs for different target operaitng systems, but still require a duplicate Cargo deb config sections. Hmm, --variant automatically adjusts the package name but I don't want that. Ah specifying name in Cargo.toml resolves the package name issue.

[kornelski]

https://github.com/mmstick/cargo-deb/blob/master/systemd.md