Issue #443 is about deprecating Torcx in favor of systemd's sysext. But it focuses on the limited use case that Torcx was for, installing multiple versions of an application, usually a container runtime. But I think systemd sysext could be leveraged in a much broader and useful way now that systemd 249 is rolling though the channels.

Flatcar has always been a bare minimum Linux distro for containers. In essence all we need is kernel + systemd + update agent (of course, a small set of support tools). But we we see many usecases where it is viable to create an image rather than use containers for everything. I’d like to create a general mechanism that could be used to create customized image rather than just adding single application versions.

An issues with the torcx method is that it's not something that gets auto-updated. So that if I maintain my own Nebraska, I can have a pipeline where I consider an update to be the core Flatcar image + whatever sysext overlay(s) I have. Alternatively, it would be cool to have a tool where I could take my overlay(s) and create a merged image from that. That would simply retain our current update mechanism.

Ideally, as a project, we could maintain only a core image + a container overlay, and maybe a kubernetes overlay. Others could create their own overlays which the Flatcar team does not have to support or worry about but greatly expands the applicability of the Flatcar project and brings its features of auto-updates and immutability to many more areas.

But the key is that it would retain all those features: immutable, auto-updatable, minimal. In this way we're not just making another package manager. The focus should be on create images and having those be able to update.

Roadmap

• Deprecate Torcx in favour of e.g. systemd-sysext #443 (Preshipped Docker as Docker+containerd sysext, docs for providing own sysext images)
• Extend usage of sysext for alternative container runtimes (preshipped on /usr): Support arbitrary container runtimes via provisioning-time images #447
• Use sysext for OEM tools and update them through update-engine (offered as additional payloads in the Nebraska Flatcar channel): Enable updating of OEM specific tools #60
• Support optional sysext images, e.g., for Kubernetes binaries, either auto-updated similar to the OEM tools (offered in the Nebraska Flatcar channel), or updated independently through systemd-sysupdate (possibly with Nebraska if Omaha support is added)