Materia v0.6 has been released! Much of this release also ended up being more backend refactoring, but we still had a few new features added that I didn’t want to keep from :stable any longer.

As I did for v0.5, here’s a bit of a more detailed over view for the bigger changes. If you just want the changelog, check it out here.

OCI images as a repository source

You can now specify a remote OCI image to use as your Materia repository! Simply create a bare image with the normal Materia repository file layout at / and pass it as the source URL like any other image: MATERIA_SOURCE__URL=oci://git.saintnet.tech/stryan/materia-example-repo:latest. The example repository has been updated with a mise task that demonstrates how to do so. This is useful if you’re building your repository with some automated process like Nix, or you simply don’t want to expose your Git forge over the internet.

This feature was contributed by TECHNOFAB on Github.

Quadlets and AppMode compatibility

Podman 5.8 introduced a new Quadlet type: .quadlets. These files contain multiple quadlets concatenated together, an example of which can be seen on the official Podman documentation. Materia now officially supports this quadlet type with its own implementation, meaning you don’t need Podman 5.8 to use it. Quadlets files can be included in your components and repositories like any other Quadlet type and Materia will automatically expand and install the file as its “component” Quadlet files.

On a related note, Materia now has a MATERIA_APPMODE (default false) configuration option that causes it to generate .component_name.app files for installed components. This is too improve compatibility with the podman quadlet commands, as now you can see which quadlets are a part of what component. Please note that since Materia stores data files in its own folder the app file does not contain the data files associated with the component, only the Quadlet files.

Component Script improvements

Did you know? Components can be scripted with post-install and post-removal steps, for all those tricky installation steps that need to be done imperatively or are too tedious to implement as systemd units.

Originally this feature was implemented using special setup.sh and cleanup.sh scripts included with the component, but now is done entirely through the Component manifest file and systemd one-shot jobs. Normal script resources can be specified in the new Settings.SetupScript and Settings.CleanupScript Component manifest options. When the component is installed Materia will run the specified setup script as a systemd transitive job with the name componentname-materia-setup.service. Conversely, when the component is removed Materia will run the specified cleanup script as componentname-materia-cleanup.service. These jobs are set to remain after exit so you can examine logs if needed, but running the startup job will attempt to remove any stale cleanup jobs and vice-versa.

Changelog

- refactor: planner,plan,containers,services, executor, and component loading modules have been publicized and refactored.
- feat: Component scripts are no longer a separate resource type. They are instead normal script resources that, when specified in the component manifest, are run in a transient systemd unit on installation/removal.
- bugfix: component removal ignores non-existent services
- bugfix/feat: `Overrides` now properly overrides manifests, new `Extensions` manifest option
- feat: add support for OCI images as repository sources.
- feat: experimental support for `.quadlets` files
- feat: LoadAllAttributes config setting for attributes engine to ignore host/role filtering
- feat: new `services` config block
- feat/refactor: remote components use new source format
- feat: `appMode` config option to generate `podman quadlet` compatible app files

Deprecations

As mentioned in the previous release, the cleanup, cleanup_volumes, backup_volumes, migrate_volumes settings are now in the planner config section.