-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Systemd user units #17
Comments
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. |
This issue is open because it specifically concerns user units. It came after The issue is that the currently generated shell fragments invoke systemd tooling without the We should look at how the official Debian packaging tooling handles this. |
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. |
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. |
I was just coming back top delete my reply.... I finally got a response from 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. |
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. |
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.
|
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)... |
I was hoping cross-compling would be straightforward to setup, but I couldn't get gcc:amd64 installed w/o removing the arm64 arch. |
At the moment it is not possible to install a systemd user unit. I am missing an option in package.metadata.deb.systemd-units that allows to define that the service should be installed for users.
I am not an expert with debian packaging but I am willing to implement it if I get some help.
From my point of view the following points have to be considered when an user option is enabled:
Any opinions on this?
I got it working with the following scripts:
postinst:
prerm:
postrm:
The text was updated successfully, but these errors were encountered: