Add quadlet

[cryi]

Add Quadlet Support in Build Pipeline

With podman generate systemd now deprecated in favor of Quadlet, this PR integrates Quadlet into the build pipeline.

Changes

• Adds Quadlet to the build process.

Notes

• Increases tar archive size by approximately ~2MB.
• A sample build is available for review: Release v0.0.8.
• This is still a work in progress. Due to long build times, testing is slow.
• It should be ready by tomorrow or later this week based on feedback.

Please let me know if this is acceptable or if any changes are required.

Closes #120

[mgoltzsche]

Also, it would be great if you could add a simple test case here that uses the quadlet to generate a systemd unit.

[cryi]

OK, @mgoltzsche, we should be good to go. The tests are in place and everything seems to be working. The last thing to check/confirm is whether you want me to move the dependencies to libexec to align with upstream or keep everything in lib for simplicity.

By the way, I needed full builds because I was testing real deployment with an Ansible playbook. I wanted to make sure this would work for us.

[mgoltzsche]

The last thing to check/confirm is whether you want me to move the dependencies to libexec to align with upstream or keep everything in lib for simplicity.

Why is the quadlet binary stored within libexec in the first place when it is supposed to be called directly by users (or their scripts), not indirectly by podman? Do you know the reason for that by any chance?

Unless podman is calling the quadlet under the hood, I am inclined to store it at /usr/local/bin/quadlet as any other binary that is supposed to be called by users directly - after all it needs to be linked there at least.
Otherwise, given that the other binaries podman calls are already within /usr/local/lib/podman I'd prefer also storing the quadlet binary there for simplicity (so that users don't have to care about another binary location).

[mgoltzsche]

The rootless test against the minimal image variant failed due to the quadlet binary not being available there.
Since the UID the container is run with shouldn't affect the generation of the systemd unit (given that the container file is readable) and since therefore testing the quadlet only within rootful.bats is sufficient, I suggest to remove the new test case from rootless.bat.

[cryi]

Why is the quadlet binary stored within libexec in the first place when it is supposed to be called directly by users (or their scripts), not indirectly by podman? Do you know the reason for that by any chance?

/usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/libexec.
From .linuxfoundation.org

So I assume the rationale is not to let users call it directly while clearly signalling it is a binary and not a library.

But if you prefer we can move it to lib. I do not have preference in this case. 🙁

[mgoltzsche]

binaries that are not intended to be executed directly by users

Isn't the quadlet supposed to be executed by users directly?

If you're going to store the quadlet within /usr/local/lib/podman please create a softlink at /usr/local/bin/quadlet (assuming users are supposed to call itas you did within the bats test).

[cryi]

Isn't the quadlet supposed to be executed by users directly?

No. Users are not supposed to call it directly. The test I used is from redhat docs on how to test quadlet generation. Not how it is used.

systemd calls it automatically.

[mgoltzsche]

ah, okay. Then storing/linking the binary within /usr/local/bin/ doesn't make sense, of course.

Though, how does systemd know where the quadlet is?

[cryi]

Though, how does systemd know where the quadlet is?

systemd gets it from these two symlinks. On daemon-reload it runs generators and generates units automatically.

Technically we shouldn't store quadlet in containers at all. (Unless someone is going to run systemd in container, which is rare) But I assumed there is not other way to get it into the tar archive in our case.

[mgoltzsche]

systemd gets it from these two symlinks. On daemon-reload it runs generators and generates units automatically.

ah, right. Then the PR should be good. You can leave the quadlet within the libexec directory.

[mgoltzsche]

Technically we shouldn't store quadlet in containers at all. (Unless someone is going to run systemd in container, which is rare) But I assumed there is not other way to get it into the tar archive in our case.

Ideally, it shouldn't be stored within the published container image, indeed, but another image variant (new stage within the Dockerfile) could be built instead that is used only to prepare the tar archive but it would increase the complexity of the build and I don't want to block the PR from being merged just because of that.

[cryi]

Ready for a review @mgoltzsche .

[mgoltzsche]

@cryi Thanks for creating the PR btw!