Systemd user units about cargo-deb

[ximon18]

This issue is open because it specifically concerns user units. It came after systemd.md.

The issue is that the currently generated shell fragments invoke systemd tooling without the —user argument and the reporter would like a way to benefit from the generated shell fragments but with this missing argument, without having to replace entire fragments by hand.

We should look at how the official Debian packaging tooling handles this.

[jchimene]

I was just coming back top delete my reply.... I finally got a response from cargo deb that merits investigation. Thanks for your quick reply!

I've still learned a lot from this tool about building Rust on debian. I will look into the logging issue. It would certainly be nice to peek behind the curtain.

[stappersg]

I don't know what came first, https://github.com/kornelski/cargo-deb/blob/main/systemd.md or this issue. Thing I would like to known, is for which reason is this issue still open.

[jchimene]

So the #DEBHELPER# substitution does work? I've had zero success with it. I susect the lack of tests to be a clue. I looked at the krill usage. I got some things from it.

The charming thing was the cargo-deb forced the inclusion of the #DEBHELPER# sentinel, then refused to perform the substitution.

I finally gave up and wrote the stanzas manually.

[ximon18]

It works, but there's too little information printed about what it is doing and too little support for investigating why it isn't doing what you expect when it doesn't seem to work.

Back when this was first implemented cargo-deb had very limited support for logging. I believe that since changed so I would very much like to improve this, the problem is finding time to do it.

[ximon18]

Regarding the Krill example, that may not be the easiest example to learn from as it packages for DEB, RPM and Docker, on multiple architectures with cross-compilation and for multiple O/S versions, handled by Ploutos which invokes tools such as cargo-deb and cargo-generate-rpm.

[jchimene]

Agreed. I had originally written in that direction, but erased it after second thought.

Anyway :( I have to use source packaging, which means getting back to debian/rules

Just when I had cargo-deb working. Basically, I used it to generate postint, prerm, postrm, and deploy assets. There are two drawbacks: 1) I'm on arm64 trying to deploy to amd64; 2) I'm on Lima, so writing to the appropriate directories on Linux requires root:root, which ain't happening.

Basically, I'm trying for reproducible builds on a target machine. I've created .deb files locally for remote installation, but not reproducibly. So, after a few decades, I've had to immerse myself in the debian build framework. As I don't allow my toolchain to be heavily Debianized, I install the Rust toolchain from upstream; which means debian-cargo just isn't appropriate without a bunch of work.

I'd hoped to sidestep the whole heavy lift with cargo-deb, but that's not to be. Maybe cross-compiling for amd64 will help.

[ximon18]

arm64 -> amd64 with cross-compiling should work, we do the reverse.

I'm afraid I don't know what Lima is or what the issue regarding directory permissions is that you are referring to, or why you have to use source packaging (whatever that is)...

[jchimene]

I was hoping cross-compling would be straightforward to setup, but I couldn't get gcc:amd64 installed w/o removing the arm64 arch.
Lima is containerd on macos. I just realized how to better set up a dev box, so I finally got the .deb created by cargo deb to install.
source packaging is dpkg-source; which I'll use to send the source to the amd machine, build it via cargo deb, then install via dpkg.
Thanks for your interest!