> Call me when `systemctl pull ...` fetches the binary and everything else needed to run it _and_ puts the .service file in the right spot.

That would be pretty awesome, actually.

▲

o11c 13 hours ago | parent | next [-]

I can already hear the systemd-haters complaining about The One True Unix Way™ is to have tools that only do one thing even if that leaves holes in their functionality.

That seems like a `machinectl` task though.

▲

jeroenhd 12 hours ago | parent | prev | next [-]

Isn't this literally what podman-systemd does? You don't exactly run a command to pull a container, but just like systemd you place a config file in the right directory, tell podman-systemd to reconfigure itself, and run the service the standard systemd way.

▲

baby_souffle 9 hours ago | parent [-]

> Isn't this literally what podman-systemd does?

That was my point, basically.

You have two options:

1) the usual `curl` or `wget` to fetch the binary and the lib(s) and all the work of validating and putting them in place and the like and _then_ you can use a systemd/.service file to set up controls for the bin

2) podman pull and then either ask podman to make a .service file for you or write your own

because only one of the two approaches has solved the package/distribution issue, containers are _not_ "less relevant given that systemd can twiddle the same isolation bits"

	▲	zdw 4 hours ago \| parent [-]
		What "validating" does docker/podman pull do that is in excess of a curl of a file? One of the advantages of a real package manager is that it checks signatures on the content that is downloaded. The supply chain on a linux distro's package repos is much harder to break into than typosquatting into a docker registry somewhere.

▲

speed_spread 13 hours ago | parent | prev [-]

That would mean systemd entering package management territory. Now THAT would not be well received.

	▲	zdw 12 hours ago \| parent \| next [-]
		IMO, docker layering over the OS's built-in package management and update lifecycle in an incompatible ways is far worse than systemd replacing the init system and other service management functionality. Back in the old days (late 90's, early 2k's) as a sysadmin I'd often write scripts to chroot or in other ways isolate services rather than run them as root, so extending the init system to handle those features feels like it's a logical extension, not a incompatible replacement.
	▲	jeroenhd 12 hours ago \| parent \| prev [-]
		systemd-sysupdate already exists. systemd won't run the software repository of course, but with systemd-sysupdate together with some overlay mounts you can get Steam Deck-like ease of use system updates. For software management in R/W environments, there's the podman + systemd combo that'll let you run containers like normal systemd services.